text:
Can I send bitcoins straight from an ATM to a vendor?
I want to buy something from a vendor on who accepts bitcoins.
Is is possible to go a bitcoin ATM and purchase bitcoins sent directly to his address?
Or do I have to purchase the bitcoin and have in my wallet then sending it to the vendor.

I think it is best to transfer to a wallet you control first.
This gives you full control of the transaction you send to make payment tp the vendor. This may be important in some situations. For example:
When a vendor gives you a payment address, it may come with a condition of sending payment within a certain amount of time (1 hour, for example). If you buy from an ATM, the ATM operator may only send a transaction to pay all customers once every couple of hours. So if you try to pay the vendor directly from the ATM, the vendor's payment page might time out by the time the payment is confirmed. In that case, you'd probably have to contact their customer service to resolve your order.


text:
Scalability problem: is the end of Bitcoin near?
I was reading in Wikipedia that the blockchain can only handle around 7 transactions per second:
https://en.wikipedia.org/wiki/Bitcoin_scalability_problem
With the soft fork for SegWi, I can imagine it could handle a little bit more, maybe 10 transactions per second.
That would mean that in one day we could have:
60 second * 60 minutes * 24 hours * 10 transactions = 864000 transactions/day
Here the official chart showing that we are often getting close to 400000 transactions/day
https://www.blockchain.com/charts/n-transactions
Does that mean that when we double the number of transactions, Bitcoin cannot scale anymore? Am I missing something?
If that's the case, considered the recent bull crypto market, we can expect there is a high chance Bitcoin reaches the maximum number of transactions per day, which will cause the crash of the Bitcoin price and a big shift in the crypto world.

Does this answer your question? Are there any studies into the size of the blockchain scaling over time?

hmm, so it seems to understand the problem doesn't exist, although it's not totally clear why it doesn't

Perhaps also interesting: https://bitcoin.stackexchange.com/q/63375/5406

To be honest, while this question very much asks about the same thing as the question @m1xolyd1an posted, I'd consider both answers on that other question to be fairly outdated.

One more thing to consider besides scalability is miner subsidy /reward which will completely go away one day.

It's not a scaling, it's a pricing problem. Higher fees are important to Bitcoin in the long run. Eventually block subsidy will run out: 18,553,300.40 of 20,999,999.9769 BTC have already been mined. As that happens, mining is transitioning to be driven by fees. Currently fees are undervalued - consider how much it costs to transfer a significant amount of gold across the world. For smaller transactions there is Lightning Network.

"we can expect there is a high chance Bitcoin reaches the maximum number of transactions per day, which will cause the crash of the Bitcoin price" - Assuming your premise is correct, can you explain why that would cause a price crash? I don't think you can just assume that, to be honest.

TL;DR:
No, the end is not near—we're just getting started. 20× is boring, let's figure out how to do 100,000×.

Let's first talk about what we are trying to achieve. We are not actually trying to increase just the number of transactions. What we're actually trying to do is to grow the network's utility: allow more people to use Bitcoin with better privacy, UX, features, and security.
While increasing the count of transactions would increase the utility, it would do so only linearly. Ten times the cost for ten times the utility—it's a bit trite. It also leads down a path that endangers other properties that we relish about Bitcoin: e.g. financial privacy, rules without rulers, censorship resistance, and the ability to validate the blockchain individually. So, instead, we aim to get leverage on the cost.
For example, stop thinking in terms of transactions, but rather think in terms of payments. By batching multiple payments into one transaction, the transaction count doesn't increase, but for a slight increase of the transaction weight, we can increase the payment count. You mentioned segwit which introduced new output formats that have less transaction weight for equivalent effect. The upcoming taproot soft fork will add another weight efficiency improvement in the same vein.
Networks scale in layers. We can use the base layer of Bitcoin as a foundation to build other services on top. These other layers can operate with different trade-offs and make use of the base layer as a "court" to resolve contracts and settle disputes. An example is the Lightning Network which facilitates instant payments and enables a user to perform manifold payments via a single base layer transaction to open their channel. Timestamping of events and documents has moved from one nulldata output per timestamp to off-chain data structures that anchor to a single output per batch. Sidechains like Liquid and Rootstock provide new scripting and privacy capabilities, but limit the on-chain cost by performing most transactions in their own blockchains.
By being restrictive in the use of the base layer, the network forces us to do the hard work to make efficient use of a scarce resource. It's also honest in setting expectations: we would never be able to put every imaginable payment on the base layer, so kicking the can down the road by doubling the payments a few times only delays the necessary work. However, after exploring other avenues, and squeezing the most out of a small base layer, we can always come back to talk about increasing the base layer capacity, eventually.

The answer to this question is not entirely clear, as nobody can predict the future to see how successful the bitcoin network will ultimately be, and scaling to meet the financial demands of the world is quite the task.
That said, there is an important point to understand before exploring this question further: the number of transactions that happen on-chain do not map 1:1 with users making payments. The word 'transaction' is maybe a bit of a misnomer here unfortunately, it might be more appropriate to call it a 'settlement', as a single on-chain transaction can account for and settle a potentially unlimited number of payments. I think this article does a good job of describing this in detail.
What this means is that there are a lot of different ways that a user can store and transact value that is backed by the bitcoin network, without actually sending their own on-chain transaction! In some cases, the user may not even need to send an on-chain transaction at all.

Scaling via 'off-chain' solutions
There are a number of known methods to scale the number of transactions that users can engage in (see Murch's answer here):

The lightning network (and other payment channel techs)
Lightning channel factories
Federated sidechains
Custodial off-chain services

The general idea of these solutions is that a single bitcoin transaction can be crafted in a way that allows users to exchange value without sending further bitcoin transactions. Each of these methods requires additional trust/security considerations, but many users are willing to make these trade-offs for increased utility/functionality.
There are some other ways to transfer bitcoins without sending an on-chain transaction, a few of which are detailed in this answer. But some of those solutions (eg the OpenDime) are interesting novelties, more than widely employed solutions.

Scaling via 'on-chain' solutions
There are also ways to scale the number of bitcoin transactions that the network can handle, to copy paste from Murch's answer that is linked above:

Examples:

Blocksize/blockweight increase
Faster blocks
The witness discount of segregated witness
Smaller size of Schnorr signatures
Bellare-Neven signature aggregation
Key aggregation

Additionally, batching payments can provide savings in both blockspace, and transaction fees.
Note that there are very important engineering considerations when attempting to scale the network by altering these on-chain parameters. As example, increasing the blocksize drastically can provide a linear increase in transaction throughput, but it also greatly increases the resources required to run a node on the network, which is damaging to the network's health. Without a large number of independent node operators, some of the network's most important properties (eg. censorship resistance) will be substantially degraded.

If that's the case, considered the recent bull crypto market, we can expect there is a high chance Bitcoin reaches the maximum number of transactions per day, which will cause the crash of the Bitcoin price and a big shift in the crypto world.

I don't think so, it seems that the current rhetoric of users (investors) is not "this is valuable because we can send a huge number of transactions!", but rather, "this is valuable because it is a scarce digital object with strong guarantees of censorship resistance and an incorruptible economic policy".
Of course, serving a larger audience of people is desirable, but just because the system hits its max throughput does not mean it will suddenly fail. In fact, such situations serve as great motivation for users to find more efficient ways to transact. As example, a recent period of network congestion lead to a great number of users turning their attention to the issue of poor fee estimation present in some wallets.
If nothing else, consider that even if bitcoin cannot scale to meet daily global transaction demands, it may still be an incredibly useful and valuable technology nonetheless! As analogy, consider that gold is extremely valuable, yet it is very rarely used in day-to-day transactions. (I don't mean to imply that this is the ideal future for bitcoin, I am hopeful it will continue to scale, but it is something to be considered in the extreme of OP's question "will it fail if it hits max transaction throughput?").

source: Stack Exchange

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

sort: votes


text:
What does is mean to have input from multiple wallet addresses?
I've trying to parse some data from the blockchain as provided by blockchain.info
My question is about transactions that have multiple inputs like this one:
https://www.blockchain.com/btc/tx/0370881edfb32d3a7059bbbec6d923add2e016c41cdc9abafd1f1c52adf3ac9e
What does is mean to have input from multiple wallet addresses?

Are each of the wallets mentioned on the left hand side here always from the same person (ie. perhaps change wallets)?
Or, is this transaction taking inputs from multiple (unrelated) people/wallets?

Are each of the wallets mentioned on the left hand side here always from the same person (ie. perhaps change wallets)?
Or, is this transaction taking inputs from multiple (unrelated) people/wallets?

It could be either. A single user's wallet might consume many UTXOs when crafting a transaction, but it is also possible for two (or more) people to supply inputs to a transaction, and they can do so without having to trust one another. So a transaction could have many potential participants, on the input side, and output side.
See:

Common input ownership heuristic info: 1, 2.
Coinjoin
BIP 174 - partially signed bitcoin transactions - Full BIP 174 text
In depth info: Bitcoin Privacy Wiki

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


text:
Is Block Finalization a valid development to remove the threat of 51% attacks?
https://www.reddit.com/r/btc/comments/bq8cqo/btctop_currently_has_51_hashing_power/eo2p4md?utm_source=share&utm_medium=web2x
A recent comment from a Reddit user in response to BTC.top acquiring 54 of the Bitcoin Cash has hate noted that a Block Finalization development removes the threat of a 51% attack.
I have never heard of block finalization before but my understanding is that it results in nodes reject the altering of blocks once they have reached a certain amount of confirmation in the blockchain. At the moment, I believe it stands at ten confirmations in the Bitcoin Cash blockchain.
Is this a valid development? Are there limitations to it?

The fact that it's on r/btc should tell you enough: bull pushed by scammers.

If ‘block finalization’ is needed, then your chain is broken. I say this because PoW is the method by which the Bitcoin network maintains consensus, and so the only reason we may introduce a ‘block finalization’ is if we worry that PoW will not be able to accomplish it’s job. If PoW cannot accomplish its job, then the system is already broken. It really is quite simple.
Consider: if 51% attacks are happening, and malicious miners are reorging the chain every few blocks, what good is ‘block finality’? The system is already seemingly broken.
Adding any sort of ‘block finalization’ can also introduce new issues and attacks:
Consider: if some nodes on the network somehow have a different history that goes back more than ten blocks, then the network will never be able to reach consensus without manual intervention.
So if a node is Sybil/eclipse attacked and fed a fake history by its peers, it will now never be able to get back onto the longest valid chain, because it will not follow a reorg of more than 10 blocks depth. In the face of a network at risk of 51% attacks, why should we assume that this would not happen? Rewinding 10 blocks could be quite easy for an attacker with a majority of hashpower, and so ‘block finalization’ just means the dangers associated with eclipse and Sybil attacks are far greater than before. Without block finalization, a node only needs one honest peer at any point in time, but with block finalization, a node needs one honest peer every ten blocks. A small but extremely important distinction.
Further, there are even situations in which this could cause issue without any malicious actors involved. If some part of the internet’s backbone infrastructure went down and isolated some portion of nodes and miners temporarily, then how would they ever get back in sync with the wider network? They wouldn’t be able to, without manual intervention.
So ‘block finality’ is not a technically sound idea. It is a bandaid for an already broken network.


text:
Is it possible to splice a new participant into a LN channel factory?
I am reading paper named "Scalable Funding of Bitcoin Micropayment Channel Networks".
If Alice, Bob, and Charlie created a channel factory, I thought that only these three people can make a payment channel within themselves. However, the paper says "Users will be able to enter the system with one blockchain transaction and then open many channels without further blockchain contact." (page 3).
In the above case (i.e., Alice, Bob and Charlie created a channel factory), Hook transaction becomes 3-of-3 multisig. If Diana wants to join the channel factory, Hook transaction consisted of three peoples already. so I think Diana can’t join in their channel factory.

There is no example in this case in the paper(above picture). Is the way I understand correct ? or not ?
And I wonder how to refund without closing and re-opening ? As you can read in this paper, When a party enters a channel factory, the deposit that the party input is already set at that moment. or.. the meaning of refund in here is moving funds to different channels ?

You are correct. It is not possible to get Diana into the Channel Factory without a transaction that closes and reopens with Diana.
Splicing-in and splicing-out as explained by Decker et al. in the paper you mention is not secure.
Imagine the following situation:

Alice, Bob and Carol spliced out Dave by creating a new Allocation within the same factory, similar to how Decker et al. explain in figure 9 of their paper. Bob and Alice might tell carol that R^2 is the last update of their channel, but actually they updated to R^3, completely invalidating the new allocation. Carol might have accepted payments in such new factory that will never be reflected. For this same reason, splicing in users is also not secure.
Ranchal-Pedrosa et al. refer to this problem as the broken factory, and suggest alternative factories constructions, comparing them, in their paper Lightning Factories.


text:
I cann't send BTC on wallet Blockchain
When I try to send BTC i get error: BitcoindException(super=com.neemre.btcdcli4j.core.BitcoindException: Error #-26: 66: mempool min fee not met, code=-26).
My wallet is on blockchain.info, I set hight fee: priority, 1000,2000 and 3000 sat/b. And i get same probleb. Help me plz. Why can not I send btc??

If your wallet is on blockchain.info, why is this question tagged with [tag:bitcoin-wallet-app], which is an Android mobile app that has nothing to do with blockchain.info?

If you're really sending from blockchain.info, then this is something you have to take up with their customer support.

I wrote on the Sapport more than once. Saport is overloaded now. Do not unsubscribe. I thought maybe someone had this situation.

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


text:
Can someone explain in detail how p2pool payout works?
From reading the wiki on https://en.bitcoin.it/wiki/P2Pool#Donating_to_P2Pool_miners I got the impression that the pool members included each of the share payments directly in the coinbase generation transaction as multiple txouts.  But after spending some time looking at  example p2pool blocks (for example this one:
https://blockchain.info/block/000000000000000007508100b6d96c3e1d1016835db41a32532d53ebd0207039)
I see that the whole output goes to one wallet (starting with 1KFEH7...). (EDIT: My error this was a F2Pool not P2Pool. Actual P2Pool coinbase do pay to multiple txouts.) In some blocks I do see this wallet sending money to many people  (but not in this example one) but this leads to a couple questions:
1) How does the system enforce these payouts?
2) How does the system get it's intitial seed money for the first payouts?

Are you sure the link you gave is for a P2Pool block? I just found this resource which lists the blocks solved by the P2Pool. This was the top block listed, and it has many outputs in the generation transaction, paying to each of the miners in a pool who contributed to the share chain within the last N blocks (N is some pool-specific number).

1) How does the system enforce these payouts?

As far as I understand it, blocks on the share chain are only accepted by the other members of the P2Pool if they have appropriate payouts. So, while you could make a block that pays all to you, you wouldn't get that block accepted on the share chain, and you wouldn't get credit for your work. To have the appropriate payouts, the block must split up the reward to each of the solvers of the last N blocks. If a miner has multiple shares in the share chain within the last N blocks, their payouts can be grouped into one transaction output.

2) How does the system get it's initial seed money for the first payouts?

P2Pool works with PPLNS (Pay per last N shares), which is pool hopping resistant. P2Pool also doesn't give any payouts until someone in the pool solves a block. Essentially, all pool payouts are awarded in an actual bitcoin block, so there's no need to have a fund to distribute rewards set up ahead of time.

Thank you very much.... the block i quoted was NOT a P2Pool but rather F2Pool.  blush.  Also thanks for all the info!

@DrEntropy, no problem. If you haven't already, check out the P2Pool Wiki, it's pretty descriptive.

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


text:
Dogecoin daemon (dogecoind) returning "Method not found" error
I am trying to play with dogecoin deamon useing node-dogecoin library.
Unfortunately most calls I try return "Method not found" error
for example :
 dogecoin
.auth('MyUserName', 'mypassword')
.getNewAddress()

The only method I've managed to run successfully so far is :
.getmininginfo();

which makes me feel that deamon is working.
what could be the problem?
thanks.
Edit : debug.log file.
2015-02-16 05:47:57 GetNextWorkRequired() : RETARGET; target: 60, actual: 150, modulated: 71, before: 1b3b3a63, after: 1b461628
2015-02-16 05:47:57 UpdateTip: new best=7db9ae84010185d708f5f1236dd5102b5b4c904bb1099c388485721d2e5b449e  height=194311  log2_work=59.309095  tx=9406440  date=2014-04-24 07:24:42 progress=0.292254
2015-02-16 05:47:57 ProcessBlock: ACCEPTED
2015-02-16 05:47:57 ProcessBlock: ORPHAN BLOCK 152, prev=793c3f50e6725b056963fae977131f16b15b0d1b7e1c9c550fe8cec9a092f126
2015-02-16 05:47:57 ProcessBlock: ORPHAN BLOCK 153, prev=d54393112610200c1d47fb7ced2f9eb8d33f241fec209dfb2cc4502b462b5cb3
2015-02-16 05:47:58 ProcessBlock: ORPHAN BLOCK 154, prev=3a2c422d3996c80bceef7e0a6901178ddf84d00c97d08990be63b4028e99abf7
2015-02-16 05:47:58 ProcessBlock: ORPHAN BLOCK 155, prev=2dbaee58af92c0c92ea500bf88992c02ddddfb5ca7e3c2a1416b27c4f1b9cb9d
2015-02-16 05:47:58 ProcessBlock: ORPHAN BLOCK 156, prev=9058c7d4c4439c074ffb58213a169ed524c142877230cb1823a637c468aec544
2015-02-16 05:47:58 ProcessBlock: ORPHAN BLOCK 157, prev=012a8d8caa54c4115d05433390c060af3ed9d35f4761487bdf94a47aada02335
2015-02-16 05:47:58 ProcessBlock: ORPHAN BLOCK 158, prev=0840f526c0828e6fe1dc9513dfd34acbf3bae8e8bbef719807d7f50180bf3c80
2015-02-16 05:47:58 ProcessBlock: ORPHAN BLOCK 159, prev=4b2ae3b0e5d79b8eb01146128ce98f608d42c450dca75aebe47d8ea072e144ff
2015-02-16 05:47:59 GetNextWorkRequired() : RETARGET; target: 60, actual: 29, modulated: 57, before: 1b461628, after: 1b42950c
2015-02-16 05:47:59 UpdateTip: new best=67981a7bdbbf610ce6bc35ac7065aadbb02c66bbfdb811a133692bc44731aec4  height=194312  log2_work=59.309103  tx=9406445  date=2014-04-24 07:24:56 progress=0.292254
2015-02-16 05:47:59 ProcessBlock: ACCEPTED
2015-02-16 05:47:59 ProcessBlock: ORPHAN BLOCK 160, prev=3872f8f2114d76d82fce03f96a9183f2e623627f0395b0166ecacd4bd604bc47
2015-02-16 05:47:59 ProcessBlock: ORPHAN BLOCK 161, prev=92f508ebcd8f8c5495d14cfbde46a82a6fd40ba00278b8f6d9547df1fb478e99

w.

Have you tried getnewaddress in lowercase?

@NickODell. Not sure if it is working ok but after building on another machine it stop throwing that error. On the other hand debug.log grows like crazy.

@wonglik can you provide relevant debug.log entries here?

@WizardOfOzzie edited post and attached logs. My debug.log file within two minutes grows about 150kB

In case anybody has similar problem in the future. It seems that my dogecoind build was somehow incomplete. node-dogecoin was trying to call methods that were not available for some reasons. Building from scratch again solved the problem.
As for the log, it seems that it grows at the beginning but stabilize after a while.


text:
Incoming connections
how can I isolate my node from all type of incoming connections and interaction with the bitcoin network?
I need to make heavy querys in my own node and I need all my hardware recources for me. Thanks.
And my timeout is not working...
rpcuser=user
rpcpassword=test
rpcbind=127.0.0.1
rpcallowip=127.0.0.1
rpcport=8332
daemon=1
maxconnections=20
maxuploadtarget=250
txindex=1
maxuploadtarget=20
rpcclienttimeout=1800

# Disable incoming connections
listen=0

UPDATE:
Select privacy and your node will going to not accept incoming connections
https://jlopp.github.io/bitcoin-core-config-generator/#config=eyJuZXR3b3JrIjp7Imxpc3RlbiI6MCwibWF4Y29ubmVjdGlvbnMiOjB9fQ==


text:
Fixing 'Connection Reset by Peer' Error When Calling bitcoind REST API in a Container
Problem: Unable to Access bitcoind REST API from Host Machine
Description: I have bitcoind installed in a container, and I can successfully make REST API calls from within the container. However, when attempting to make the same calls from my host machine, I encounter the following error:
isudoajl@f38-server:$curl localhost:8333/rest/chaininfo.json
curl: (56) Recv failure: Connection reset by peer

Configuration:
bitcoind configuration (bitcoin.conf):
server=1
rpcuser=xxxx
rpcpassword=xxxx
rpcallowip=192.168.1.0/24
rpcport=8332
rest=1
txindex=1

Container is listening on port 8333
Troubleshooting Steps Taken:
Verified bitcoind configuration settings.
Checked container's listening ports.
Attempted various curl commands from host machine.
Question: Is there a solution to this problem? I've been troubleshooting for days without success. Any help would be greatly appreciated.


text:
Extremely slow blockchain syncing issue on RaspBerry Pi 4 with Raspiblitz
I'm encountering a significant delay in synchronizing the blockchain on my Raspberry Pi 4. Even after 11 days, the sync progress is only at 68%. I'm using a brand new Raspberry Pi 4 with a 1TB USB 3.0 drive and a 400mbps wired internet connection. Despite adjusting various settings in my bitcoin.conf file, I haven't seen any improvement in syncing speed.
I've ensured the wired connection is stable, and the hardware seems to be functioning properly.
I am getting less than 10 peers, usually dropping off to around 3.
Blocks are estimated to be coming in every 2 seconds on average.

Does this answer your question? bitcoind sync time incredibly slow also see Raspiblitz slow sync performance


text:
How to create and sign a segwit transaction using any npm pacakge
So I am using this NPM package ( https://www.npmjs.com/package/bitcore-lib )
to create and sign a Bitcoin legacy transaction locally and it was working fine for legacy.
But when I tried to do the same for segwit addresses I started getting this error when i submit that raw into sendrawtransasction node method.
mandatory-script-verify-flag-failed (Witness requires empty scriptSig)

So I think the issue is with this package as the structure of this payment is not what is required for a SegWit transaction.
So my main question is is there any package in javascript I can use to create and sign a transaction? the main payload I have is
receipentAddress, senderAddress, amount ( in satoshis ), and privateKey in WIF.

any help or clue is highly appreciated.
//edit:
rawhex:
02000000017d155e9418b60ee26fe189d4381a1fcd5aac1d8eed5216c210e6f6e7a6d86b37010000006a47304402204d6b08238b2eafbf18b7b940a4bbb59c1cc610a1d5e05d2ed72f78f9a6035b890220513a33b2461f12f711776063a54d62913adef76eb40f62ad0eac3f16577c572e01210312bc181f50c9dff7d5ebe77d4df32a9ae2e5b0530b5a4a9c4b8b88647911a883ffffffff029065000000000000160014dc804b4f932f37f77ff9a4f843c845dc3cc3d30164f20300000000001600149518ea8b88e82e82d9003fa3f7518e15180cc58500000000

edit: added code below
const axios = require('axios');
const bitcore = require('bitcore-lib');

async function generateAndSignTransaction(payload) {
  let { address, privateKey, recipientAddress, satoshis, chain } = payload;

  try {
    async function fees() {
      try {
        let key;
        if (chain === "testnet"){
          key = 'test3'
        }else {
          key = 'main'
        }

        let r = await axios.get(`https://api.blockcypher.com/v1/btc/${key}`);
        let feeObj = new Object;
        feeObj["High_fee"] = r.data.high_fee_per_kb;
        feeObj["Medium_fee"] = r.data.medium_fee_per_kb;
        feeObj["Low_fee"] = r.data.low_fee_per_kb;
        return feeObj;
      } catch (error) {
        console.error(error);
        throw error; // Propagate error
      }
    }

    let res = await fees();
    let fee = res.Low_fee;

    let url = `https://blockstream.info/${chain}/api/address/${address}/utxo`;
    res = await axios.get(url);

    console.log('UTXOS: ', res.data);

    let i = 0;
    let utxos = [];
    let balance_utxos = 0;

    while (balance_utxos <= satoshis + fee && i < res.data.length) {
      let utxo = {
        "txId": res.data[i].txid,
        "outputIndex": res.data[i].vout,
        "script": bitcore.Script.buildPublicKeyHashOut(address).toString(),
        "satoshis": res.data[i].value
      };
      utxos.push(utxo);
      balance_utxos += res.data[i].value;
      i++;
    }
    console.log('UTXOS 02: ', utxos);

    let tx = new bitcore.Transaction();
    tx.from(utxos);
    tx.to(recipientAddress, satoshis);
    tx.change(address);
    tx.fee(fee);
    tx.inputs.forEach(input => {
      input.setScript(bitcore.Script.empty());
    });
    tx.sign(privateKey);

    console.log('Tramsactopnm: ', tx);
    console.log('Tramsactopnm data: ', tx.serialize());

    let txnHex = tx.toString();

    return { txid: txnHex }; // Return the serialized transaction
  } catch (error) {
    console.error('Error:', error);
    throw error; // Propagate error
  }
}

module.exports = { generateAndSignTransaction };

From error message, I guess you sign your transaction in a same way when spend legacy address, because it literally means your script sig is not empty(it must be empty for segwit spend as script sig must be placed into witness stack). I don't think it would be problem with bitcore-lib, but you might use my open source bitcoin-sdk-js as an alternative as it supports segwit spend.
Below code works.
import * as bitcoin from 'bitcoin-sdk-js';

const privkey =
  'e6c58327b4bf1314296bba7adb66f94c36ea5611ac07830c229aa7ee6f9caac3';
const toAddress = 'tb1qmjqyknun9umlwlle5nuy8jz9ms7v85cp7k2nfe';
const toValue = 300000;
const txHash =
  '8bcd197873dbff5cc67cb3e0b1cbbdf097c7af94b0e9365adecb424e408294bf';
const inputValue = 310981;

const tx = new bitcoin.Transaction();

await tx.addInput({
  txHash: txHash,
  index: 1,
  value: inputValue,
});
await tx.addOutput({
  address: toAddress,
  value: toValue,
});
await tx.signInput(privkey, 0);

const txHex = await tx.getSignedHex();

here is the raw hex
02000000017d155e9418b60ee26fe189d4381a1fcd5aac1d8eed5216c210e6f6e7a6d86b37010000006a47304402204d6b08238b2eafbf18b7b940a4bbb59c1cc610a1d5e05d2ed72f78f9a6035b890220513a33b2461f12f711776063a54d62913adef76eb40f62ad0eac3f16577c572e01210312bc181f50c9dff7d5ebe77d4df32a9ae2e5b0530b5a4a9c4b8b88647911a883ffffffff029065000000000000160014dc804b4f932f37f77ff9a4f843c845dc3cc3d30164f20300000000001600149518ea8b88e82e82d9003fa3f7518e15180cc58500000000
and the error is
mandatory-script-verify-flag-failed (Witness requires empty scriptSig),
checking on this pkg, will keep you updated.

As I guessed you are trying to spend segwit output in a legacy way(which is wrong). You must move script sig part(which is 47304402204d6b08238b2eafbf18b7b940a4bbb59c1cc610a1d5e05d2ed72f78f9a6035b890220513a33b2461f12f711776063a54d62913adef76eb40f62ad0eac3f16577c572e01210312bc181f50c9dff7d5ebe77d4df32a9ae2e5b0530b5a4a9c4b8b88647911a883) to witness stack(at the end of tx hex) and also need to add segwit flag, mark and witness item count. I think the signature itself would be also wrong as the segwit message to sign is different from legacy. You can check BIP143 for specific semantic.

brother, i dont understand all these that much, I just want a tool or pacakge to work, and i will only provide the payload which is
{
address: 'tb1qj5vw4zugaqhg9kgq873lw5vwz5vqe3v9uldtdu',
privateKey: 'L4xJPRKG4QpqeFraSqJQiY6iPd364H8E9jrmtZkqVw2WQVCejBcj',
recipientAddress: 'tb1qmjqyknun9umlwlle5nuy8jz9ms7v85cp7k2nfe',
satoshis: 26000,
chain: 'testnet'
}
and the code should give me hex which works. the package you shared doesn't have a proper doc, and code is also outdated. anyways I'll try to make it work. thanks for the time.

I'm sorry I just pushed tx to testnet for test accidentally with the private key you provided and it works well. I edited my answer with code.
If you need testnet btc let me know I will send to you.

Hi Hyunhum, that's really great that this code works I also want to try this but i have nothing left unspent, i have tried many faucets but haven't received any yet, can you please send me back?

I have tried this code although not sure about how you fetched priv key from wif, i have used bitcoinjs-lib for that, the hex it generates is giving me bad-txns-inputs-missingorspent
error, hex is: 010000000001017d155e9418b60ee26fe189d4381a1fcd5aac1d8eed5216c210e6f6e7a6d86b370100000000fdffffff0190650000000000001600149518ea8b88e82e82d9003fa3f7518e15180cc58502483045022100d4f0c6e6b5fdca9839a3a75f1f9daaa6c9d083c57bd731d6a78f0d5f448bc6de02205015a6b67abde663f7772e4c499e43ad920de5d4ac447c274ceb49bcfcb53be8012103cc5b73e26e04b2e9cb71723f7669ff611127e219fd14ad522c649272faef8a7500000000

because that tx is already broadcasted by me(in other words it is spent). I will send u test btc. u can try with unspent transaction

No actully I have now tried with difftrent account where the utxo is left, but still get this error.

No you didn't have utxo left as you can see https://blockstream.info/testnet/address/tb1qj5vw4zugaqhg9kgq873lw5vwz5vqe3v9uldtdu
I sent you same amount in transaction id 8bcd197873dbff5cc67cb3e0b1cbbdf097c7af94b0e9365adecb424e408294bf, try using this

Let us continue this discussion in chat.

I have tried it with this account also it sends me a hex:
010000000001017d155e9418b60ee26fe189d4381a1fcd5aac1d8eed5216c210e6f6e7a6d86b370100000000fdffffff01803e000000000000160014dc804b4f932f37f77ff9a4f843c845dc3cc3d30102473044022048f3104cb19a1f2f61cae8c40a6f6d7ec1d9bbb117a918533e852bfc54b6eaab022077c24324009bae1db18ed73c1e4c5fe03d54a2c89e63ff58fb4839fb7829d36d01210312bc181f50c9dff7d5ebe77d4df32a9ae2e5b0530b5a4a9c4b8b88647911a88300000000
and when I pass this in node method sendrawtransaction it returns {"bad-txns-inputs-missingorspent"} error. can you please help me to debug this, thanks


text:
where did my previous block of receiving addresses in my electrum wallet go?
So I have an airgapped (using tails os on an old laptop) electrum (cold storage) wallet that I previously added additional receiving addresses by increasing the gap limit: wallet.change_gap_limit(110). I then copied those additional addresses to my connected (online) electrum watch-only wallet. I have used up enough of the additional receiving addresses that I went back into my airgapped wallet to generate another block of receiving addresses.
However, when I open my airgapped wallet, I don't see the previous block of additional receiving addresses I generated; I only see the original 20 receiving addresses the wallet had when I created it.
So I did read this warning in the Electrum FAQ:

WARNING: Addresses beyond the gap limit will not automatically be recovered from the seed. To recover them will require either increasing the client’s gap limit or generating new addresses until the used addresses are found.

So I ran the same command I previously ran to increase the gap limit, expecting (hoping) to see previous addresses I generated, but the addresses added to the addresses tab in electrum are a different block of addresses, which I confirmed with: diff listPreviousAdds listOfNewAdds. Not one address from the previous block of generated addresses shows up in the new block of generated addresses.
So going by the warning message I pasted above from the Electrum wallet FAQ, how many new addresses might I need to generate to find the previous addresses I generated and have sent BTC to?
Update: Ok so I figured it out. I ended up mixing addresses from two different wallets, of which I have the seed for both, so ultimately all is well. Almost all of the addresses have been account for between the two accounts. I am still missing a couple that have been funded, but I think I just have to tweak the gap limit on one or both to find the remaining few.
It was never my intention to run two wallets, so now I need to decide whether to do so or consolidate and transfer the BTC in the wallet with the least amount to the other wallet and discard the second wallet. I wonder what benefits, if any, there could be in running two wallets?
I would still like to know if is there a better way to deal with adding and managing new receiving addresses using electrum, as this procedure seems a little hacky.
I do know from previous experience that if an online watching wallet has a corresponding cold storage wallet's public key imported instead of just receiving addresses, that new addresses seem to get auto-populated as the existing address pool start to get used up. With security being my primary concern over convenience, I wonder which of these two methods of address generation, if either, could possibly be deemed less secure, for example, one might potentially present a larger attack surface.
Thks in advance.

When you created a wallet with Tails OS, did you store the wallet you created or are you creating a new wallet each time you start up Tails OS?

@Murch the wallet is uniquely named and is the one I login with my password and so open when after logging into tails os.

Hey @naphelge, thanks for coming back to answer your own question. Could you please post the answer portion of your question as an answer post? Self-answers are encouraged here. Regarding your new questions, it would be best to start another topic, but I would recommend not to delete any wallets that have been used. Perhaps it would be easiest to use what you have learned to create one fresh wallet, move everything there, and keep a (well-documented!) backup of the old wallets along with it. Glad that you found your addresses.


text:
How to make a simple payment with the python-bitcoinlib?
I've been using the bitcoin-python library for making payments from within Python. This worked pretty simple:
>>> import bitcoinrpc
>>> conn = bitcoinrpc.connect_to_local()
>>> conn.sendtoaddress('bitcoin_address_here', 0.5)

The Readme of that library now says that it is not maintained anymore and refers to the python-bitcoinlib as a successor. So now I'm trying to wrap my head around that lib, but it seems to be a bit more difficult than bitcoin-python used to be. I now understand I can connect to the running bitcoind using the following code:
>>> import bitcoin.rpc as rpc
>>> proxy = rpc.Proxy()
>>> proxy.getinfo()
{u'connections': 36, u'errors': u'', u'blocks': 295646, u'paytxfee': 0, u'keypoololdest': 1394108331, u'walletversion': 60000, u'difficulty': Decimal('6119726
089.12814713'), u'testnet': False, u'version': 90100, u'proxy': u'', u'protocolversion': 70002, u'timeoffset': -1, u'balance': 1856000, u'keypoolsize': 101}

So far so good. The problem is now that I have no idea how I can do a simple payment. I see there is a function called proxy.sendrawtransaction(self, tx), which apparently takes a raw transaction as an argument. I have no idea how to create a raw transaction though, plus I would expect that there is some kind of send_to_address(address, amount) available, but I can't find it around the library.
So does anybody know how I can send a simple transaction to an address with the python-bitcoinlib? All tips are welcome!

I just added sendtoaddress to bitcoin.rpc.Proxy:
from bitcoin.core import COIN, b2lx
import bitcoin.wallet
import bitcoin.rpc
try:
    # This moved between versions
    from bitcoin.base58 import CBitcoinAddress
except:
    from bitcoin.wallet import CBitcoinAddress

rpc = bitcoin.rpc.Proxy()
addr = CBitcoinAddress('1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T')

txid = rpc.sendtoaddress(addr, 0.001 * COIN)
print(b2lx(txid))

Note quite as simple as bitcoinrpc, but that's the trade-off for having proper types and so forth.

Could you expand your answer to relate to the question?

Thank you for your good work and answer! I have another question. Maybe you have an answer to that as well?: http://bitcoin.stackexchange.com/questions/24802/how-to-getreceivedbyaddress-with-the-python-bitcoinlib

where is CBitcoinAddress being imported from?

Code sample from 04/2014 is out of date with current python-bitcoinlib. Slight modification here:
from bitcoin.core import COIN, b2lx
import bitcoin.wallet
import bitcoin.rpc

rpc = bitcoin.rpc.Proxy()
addr = bitcoin.wallet.CBitcoinAddress('1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T')

txid = rpc.sendtoaddress(addr, 0.001 * COIN)
print(b2lx(txid))

Tested on v0.3.0+

from version 0.5.1 CBitcoinAddressError: Version 0 not a recognized Bitcoin Address. Can you help me to fix it?


text:
How to getreceivedbyaddress() with the python-bitcoinlib?
I'm trying to use the python-bitcoinlib in my bitcoin project. I now understand how I can send a payment, but I can't find anything similar to the getreceivedbyaddress() command I normally used.
Isn't it present in the python-bitcoinlib, is there a workaround, or am I simply overlooking something? All tips are welcome!

It's probably not in there right now; look at the code in bitcoin/rpc.py and add it! Basically you just need to follow the same pattern as other RPC calls. When you're done send me a pull-req on github.

After I posted this question I indeed saw that the source code is not that difficult. Although I won't be doing it this or next week, I'll send you a pull request some time at github. Cheers! And thanks for actually creating this software! :)


text:
How do I test my wallet backup?
I follow the instructions for wallet backup and save them digitally. What's a convenient way to occasionally test my wallet backup. I want to make sure that I'm not doing something stupid & my backup method isn't creating unrecoverable garbage.
I can think of 2 ways for testing

Install the bitcoin client on another computer and import the backup & check balances
Rename my installed folder on the existing computer & do a fresh install on the existing computer.

But these methods are not very convenient. Is there a smarter way around it? e.g. a command line tool that'll check the file integrity and spit out some data with which you are reasonably confident that it's your wallet and has the right amount of coins.

You can configure Bitcoin QT to use a specific data directory, but it only looks in that place for wallet.dat.
I would (1) close Bitcoin QT, (2) move the existing [data directory]\wallet.dat to another folder (3) copy your backup into the [data directory], and (4) reopen Bitcoin QT.
Don't overwrite your existing wallet.dat with the backup!  Step (2) is pretty important in case there's a problem with the backup file.

This sounds easier than renaming the whole directory. Any idea of how I can do that for an Android/iOS client?

I'm not sure, sorry.

NEVER play around and fiddle with a working software/wallet for testing backups. Because you can make a mistake. Expert computer users destroy data regularly by mistakes in backups. And when you some time actually need a backup is the worst time for fiddling around, so better have a solution already prepared.
To verify the "account balance" on your wallet you'd need to either download the blockchain (but the pruned version is enough if you're not hardcore paranoid) and need to know which bitcoin addresses you control (="your bitcoins"). Or just look up your addresses on bitcoin.info or biteasy or other website that gives you a view onto the blockchain.
Actually it can be a good idea to continuously track your balance with a separate software. If you don't need to hide which bitcoins are yours, simply export a "watching only" wallet from your current software (it's a wallet without the keys needed to actually spend/transact/sign for your coins) and maybe import the watching wallet in some smartphone app or some web wallet, then set up some suitable notifications.
To simply verify the correctness of a wallet.dat, up to date tools may not exist. A 2011 forum thread about the original python wallet tools has a warning at the front: https://bitcointalk.org/index.php?topic=11331.0
And in another question, someone had lost their wallet.dat (or moved+renamed and forgot about it) and it appears the wallet file format is not easy to detect by anything other than the file name. So a wallet verification tool would depend on getting source code from the wallet software and knowing which file and encryption/password to verify it with.
If your backup is a "standard" wallet.dat file you have some(1) chance for it to work in many different wallet softwares and apps. Preferably test on a fresh computer that has never been connected to any network (i.e. installed without cables plugged in. Windows 95 could get hacked while the installation software was running the last phases...). Without an extra physical computer, try using a virtual machine-software and create a fresh "computer inside your computer".
If Linux doesn't scare you and your wallet software is available on linux, then you can create a USB-stick with linux on it. Linux Live USB can give you one that runs as a virtual machine, but classical Live USB sticks instead require you to restart your computer with the USB plugged in and might be tricky to get working.
Finally, if you load you wallet backup on an untrusted computer or even a smartphone, you should have prepared in advance a new safe wallet to send your coins to.
And you should NEVER keep a large amount of coins in such a way that it can all be lost or stolen if you get the phone/computer stolen or if you forget a password. Think how much USD/EUR/... cash you would carry with you on a street with risk for pickpockets, robberies, loosing your wallet by clumsiness, etc and use that as a guide for how much bitcoin you should be handling yourself. For bigger sums, first exercise with smaller sums and it is probably wise to spread your risk by using several trusted expert(2) third parties to store your coins, just like you use banks to handle savings accounts.
The time when all "banks" can be removed is not yet. Better, safer apps and hardware wallets need to be created.
(1) In http://media01.bitcoinarmory.com/InsideBitcoins_Present.pdf it is explained that wallet encryption works differently in Bitcoin-Qt and Armory, and presumably other wallet software use a weaker but more "standard" wallet encryption.
(2) MtGox has proved again and again they are not experts. Most other well-known online wallets/traders are probably trustable with some bigger sums

I agree with all your points about safety but installing VM for testing wallets is too much effort IMHO. I was wondering if there's a tool that'll verify the wallet file integrity without jumping through hoops. And it's a good point to test any method with a wallet with a tiny amount.

Best method IMHO is to restore the wallet on another (trusty) device, check the balance, spend a little amount of uBTC and verify the other address got the money. Then delete securely the test wallet. A VM in this case is very handy.
The key step is to actually spend and test everything goes as expected. If you don't do it you can't never be 100% confident the backup will work
Checking you got the right balance back is not enough because the checking itself does not require the client to actually know the private key


text:
How do I create a descriptor wallet?
Using Bitcoin Core from today (almost 0.21):
I ran ./configure. It said with sqlite = yes. ldd $(which bitcoind) shows it is linked to libsqlite3.so.
Now, I started a signet node using bitcoind -signet. It has synced.
Now I want to create a descriptor wallet. So I tried looking in the man bitcoin-wallet, but it doesn't mention it.
I tried bitcoin-cli help and it lists:
createwallet "wallet_name" ( disable_private_keys blank "passphrase" avoid_reuse descriptors load_on_startup )

I tried:
$ bitcoin-cli -signet createwallet default_wallet -descriptors
error: Error parsing JSON: -descriptors
$ bitcoin-cli -signet -descriptors createwallet default_wallet
Error parsing command line arguments: Invalid parameter -descriptors

How do I create a descriptor wallet?

descriptors is not a command-line option to bitcoin-cli, it's a boolean argument to the "createwallet" RPC. It should be "true" or "false.

descriptors is a boolean argument, so it should either be true or false. As with all RPCs, the argument is positional by default. So your command would look like
bitcoin-cli -signet createwallet "mywallet" false false "" false true

You can specify that the arguments be named so you don't have to put the position correctly. In that case, you do
bitcoin-cli -signet -named createwallet wallet_name="mywallet" descriptors=true

why is -named necessary if passing wallet_name=...?

So that bitcoin-cli knows to interpret that as <argname>=<arg> instead of a single argument. Then it can pass everything into bitcoind correctly.


text:
Bitcoin RPC works in bitcoin-cli but not in python-bitcoinrpc: No JSON object
I'm running a testnet node. I can use bitcoin-cli just fine:
>bitcoin-cli.exe getinfo
{
    "version" : 100000,
    "protocolversion" : 70002,
    "walletversion" : 60000,
[... snipped]

But when I run this python code:
from bitcoinrpc.authproxy import AuthServiceProxy, JSONRPCException
import logging

rpc_user = "rpcuser"
rpc_password = "xxxxx"

logging.basicConfig()
logging.getLogger("BitcoinRPC").setLevel(logging.DEBUG)

rpc_connection = AuthServiceProxy("http://%s:%s@192.168.1.39:8332/" % (rpc_user, rpc_password))
print(rpc_connection.getinfo())

I get this error:
DEBUG:BitcoinRPC:-1-> getinfo []

Traceback (most recent call last):
  File "<path>\rawtransactiondemo\raw.py", line 11, in <module>
    print(rpc_connection.getinfo())
[... snipped]
  File "C:\Python27\lib\json\decoder.py", line 384, in raw_decode
    raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded

This is my bitcoin.conf:
testnet=1
rpcuser=bitcoinrpc
rpcpassword=xxxxx
daemon=1
rpcport=8332
rpcallowip=192.168.1.39
bind=192.168.1.39

I'm using the python-bitcoinrpc library.

I added some code to debug what bitcoin was sending back - it turned out to be a 401 error.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">

<TITLE>Error</TITLE>
<META HTTP-EQUIV='Content-Type' CONTENT='text/html; charset=ISO-8859-1'>

401 Unauthorized.

Why was this triggered? If you look in my bitcoin.conf, and my python code, you can see that the username is different (bitcoinrpc vs. rpcuser). Changing that fixed it.
Anyways, if you get the error ValueError: No JSON object could be decoded, this might be your problem.

For anyone else finding this, and the problem was NOT a typo like in the accepted answer:
The issue for me was simply that I had my conf file in the wrong location.
I installed this on Ubuntu 20.04 and saved the conf file in /.bitcoin/bitcoin.conf, but it was looking in /home/user, which was actually ~.bitcoin/bitcoin.conf.
Saving the conf file in the correct location resolved everything.  I could now use bitcoin-cli without sudo, and the python scripts using python-bitcoinrpc.

If you're using the testnet, rpcport should be 18332.

It's not required; you just need to use the same ports on both ends. In my bitcoin.conf, I set rpcport to 8332.

@NickODell That would explain my testnet connectivity issues; I didn't realize the conf rpcport=8332 flag set port 8332 for mainnet AND testnet


text:
Getting error for transferring BTC using node js code, getting error "No inputs were signed"
I am creating a system where users will raise a request to transfer them some BTC, in my code i am using all the previous utxos of my wallet to transfer BTC, even i am signing all the utxos still i am getting error "No inputs were signed", and i get this error for line
psbt.signAllInputs(keyPair)
import * as bitcoin from 'bitcoinjs-lib';
import { ECPairFactory } from 'ecpair';
import * as ecc from 'tiny-secp256k1';
import mempoolJS from '@mempool/mempool.js';

const ECPair = ECPairFactory(ecc);
const network = bitcoin.networks.testnet; // Use 'bitcoin.networks.bitcoin' for mainnet

const estimateTransactionSize = (numInputs: number, numOutputs: number): number => {
  return numInputs * 148 + numOutputs * 34 + 10;
};

const calculateFee = (feeRate: number, numInputs: number, numOutputs: number): number => {
  const txSize = estimateTransactionSize(numInputs, numOutputs);
  return feeRate * txSize;
};

export const sendBTC = async (
  privateKey: string,
  toAddress: string,
  amount: number
): Promise<{ success: boolean; txHash: string }> => {
  try {
    const { bitcoin: { addresses, transactions, fees } } = mempoolJS({
      hostname: 'mempool.space',
      network: 'testnet',
    });

    const keyPair = ECPair.fromPrivateKey(Buffer.from(privateKey, 'hex'));
    const p2wpkh = bitcoin.payments.p2wpkh({ pubkey: keyPair.publicKey, network });

    const address = p2wpkh.address;
    if (!address) {
      return { success: false, txHash: '' };
    }

    const utxos = await addresses.getAddressTxsUtxo({ address });
    const feesRecommended = await fees.getFeesRecommended();

    let totalSatoshisAvailable = 0;
    utxos.forEach(utxo => {
      if (utxo.value >= 1000) {
        totalSatoshisAvailable += utxo.value;
      }
    });

    const numInputs = utxos.length;
    const numOutputs = 2; // Destination + Change
    const fee = calculateFee(feesRecommended.minimumFee, numInputs, numOutputs);
    const change = totalSatoshisAvailable - amount - fee;

    const psbt = new bitcoin.Psbt({ network });

    const promises = utxos.map(async (utxo) => {
      if (utxo.value >= 1000) {
        psbt.addInput({
          hash: utxo.txid,
          index: utxo.vout,
          witnessUtxo: {
            script: Buffer.from(p2wpkh.output!.toString('hex'), 'hex'),
            value: utxo.value,
          },
        });
      }
    });
    await Promise.all(promises);

    psbt.addOutput({
      address: toAddress,
      value: amount,
    });

    if (change > 0) {
      psbt.addOutput({
        address: address!,
        value: change,
      });
    }

    psbt.signAllInputs(keyPair);
    psbt.finalizeAllInputs();

    const rawTransaction = psbt.extractTransaction().toHex();
    const txId = await transactions.postTx({ txhex: rawTransaction });

    if (!txId) {
      return { success: false, txHash: '' };
    }

    return { success: true, txHash: txId.toString() };
  } catch (error) {
    console.error('Error while transferring bitcoin:', error);
    return { success: false, txHash: '' };
  }
};

This question could be improved by providing more context: What are you trying to do, what have you tried to fix your problem, where you do think is the issue in your code? Related: Why are questions asking for proofreading of long descriptions of a concept not well received?

I am creating a system where users will raise a request to transfer them some BTC, in my code i am using all the previous utxos of my wallet to transfer BTC, even i am signing all the utxos still i am getting error "No inputs were signed", and i get this error for line psbt.signAllInputs(keyPair)

I guess you don't have utxo in your address(or if there is, value is less than 1000). Try logging either utxo or psbt right before psbt.signAllInputs(keyPair) to check emptiness.

The wallet is having multiple utxos with value more than 1000

You should write a clear question here. Please do not ask people to read and understand your code to afterwards even correct it. Describe what you are trying to accomplish and only paste the part of the code that is relevant to understand or reproduce the issue.


text:
How can I have bitcoind recreate my wallet.dat?
I had to kill bitcoind, then deleted my datadir and restarted bitcoind. I assumed it would recreate and resync everything, which it did, except for the (empty) wallet.dat.
What I did was delete the separate datadir, empty the .bitcoin folder, except for the bitcoin.conf file containing my rpc credentials. I tried twice, the second time orderly stopping and restarting bitcoind, but without a new wallet.dat recreated.
What should I do get a new wallet.dat, preferably through a fresh restart (to avoid carrying over any file corruptions as a consequence of unorderly killing the daemon process)?

A wallet.dat file will be created only when you decide to create a wallet.

Since Bitcoin Core 0.21.0 (released in January 2021), no default wallet is created anymore.
This follows a change in Bitcoin Core 0.15.0 (released in September 2017) to support multiple loaded wallet simultaneously. Since then, it has no longer been the case that wallet files are necessarily called wallet.dat; they can have any name.
The ability to create new wallets through the RPC interface was added in Bitcoin Core 0.17.0 (released in October 2018), through the createwallet command.

I'm not sure to have seen the actual .dat file, probably only the (empty?) wallets folder. Could it be that bitcoind only creates that folder when it can't find a .bitcoin folder? I left it in place, to keep my .conf file, for my rpc credentials. Will the folder be created when I create a wallet with bitcoin-cli?


text:
Building bitcoind from modified "selfish" code - possible? how?
For a long time I've been trying to find out ways for running a "selfish mine" algorithm on bitcoind's regtest mode.
Now I'm wondering if my plan is feasible, at all!?
So I'll just outline my planned procedure with the hope that I will get useful hints and won't get discouraged since I believe I can achieve my goal with the help of developers and investment of some extra time:
I'm intending to change Bitcoin Core 0.10.0 source code - or a more "suitable" version - in a way that after building bitcoind, in regtest the bitcoind server that is started acts as a selfish miner.
This selfish miner shall connect to other bitcoind nodes that are instances of bitcoind, built out of non-modified code.
My idea is to change a part of the code that communicates (e.g. inv message-part!?) with other nodes: as a selfish miner, newly found blocks should only be shared with other nodes dependent on the selfish mine algorithm so I thought of implementing control structures (if, while, etc.) that work with a comparison of inv message's amount of inventory entries or a similar comparison - e.g. selfish node has found a block and appends it to its inventory and doesn't publish this block if size(selfish.inventory) > size(honest.inventory).
Now a challenge for me is to find out which part of the source code to modify? Since it consists of multiple modules that define resembling functions, parameters etc.
I'm ready to read up big amount of code, but the problem is I don't know what part is relevant for my problem.
What do you think? Is my intention realistic? What are good approaches to a solution?

I think you'll find a lot more help forthcoming (and your project will be easier for you) if you can delineate your intentions more clearly. What I'm reading is very vague. Start by defining "selfish miner" and it may be people can opine on that

thanks, I'll edit the post in a while for a clearifying things.


text:
Rise difficulty in code, still no changes after rebuild
I'm playing around with the code and tried to adjust difficulty by changing code from

bnProofOfWorkLimit = ~uint256(0) >> 1

to
bnProofOfWorkLimit = ~uint256(0) >> 20

inside code block for Regression Test in chainparams.cpp (bitcoin-0.10.0).
I configured, did make, then make install with binaries in a custom directory (not default /usr/local/bin/bitcoind !), started bitcoind in regtest mode and generated some blocks.
Somehow it feels like it takes same amount of time for generating blocks as before modifying the code.
What am I doing wrong?

UPDATE:
Changed difficulty in chainparams.cpp from

bnProofOfWorkLimit = ~uint256(0) >> 1

to
bnProofOfWorkLimit = ~uint256(0) >> 32

still getting this:
Bitcoin version v0.10.0.0-g047a898 (Fri, 13 Feb 2015 09:55:11 +0100)
Using OpenSSL version OpenSSL 1.0.1f 6 Jan 2014
Using BerkeleyDB version Berkeley DB 4.8.30: (April  9, 2010)
Default data directory /home/aliakbar/.bitcoin
Using data directory /home/aliakbar/Downloads/bitcoin-0.10.0_test1/build/bin/test1/regtest
Using config file /home/aliakbar/Downloads/bitcoin-0.10.0_test1/build/bin/test1/bitcoin.conf
Using at most 125 connections (1024 file descriptors available)
Using 4 threads for script verification
Binding RPC on address ::1 port 23333 (IPv4+IPv6 bind any: 0)
Binding RPC on address 127.0.0.1 port 23333 (IPv4+IPv6 bind any: 0)
Using wallet wallet.dat
init message: Verifying wallet...
CDBEnv::Open : LogDir=/home/aliakbar/Downloads/bitcoin-0.10.0_test1/build/bin/test1/regtest/database ErrorFile=/home/aliakbar/Downloads/bitcoin-0.10.0_test1/build/bin/test1/regtest/db.log
Bound to [::]:13333
Bound to 0.0.0.0:13333
init message: Loading block index...
Opening LevelDB in /home/aliakbar/Downloads/bitcoin-0.10.0_test1/build/bin/test1/regtest/blocks/index
Opened LevelDB successfully
Opening LevelDB in /home/aliakbar/Downloads/bitcoin-0.10.0_test1/build/bin/test1/regtest/chainstate
Opened LevelDB successfully
LoadBlockIndexDB: last block file = 0
LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=0, size=0, heights=0...0, time=1970-01-01...1970-01-01)
Checking all blk files are present...
LoadBlockIndexDB(): transaction index disabled
Initializing databases...
Pre-allocating up to position 0x1000000 in blk00000.dat
ERROR: CheckProofOfWork() : nBits below minimum work
ERROR: CheckBlockHeader() : proof of work failed
InvalidChainFound: invalid block=0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206  height=0  log2_work=1  date=2011-02-02 23:16:42

What am I doing wrong? Do I have to adjust difficulty somewhere else than in chainparams.cpp?

What am I doing wrong?

Not setting the difficulty high enough. A standard computer can do 1 MH/s SHA256d hashes, or about 2^20 hashes. That means in your scenario, solving a regtest block will take about 1 second. If you want it to take longer, increase the difficulty.
Also, note that if you're using an 0.9.* version of bitcoin, then setting the regtest difficulty to below ~uint256(0) >> 16 won't really do much, as the mining code won't even check a result that doesn't hash to below that difficulty.
If you're using the most recent code, though, then rather than adjusting the regtest parameters, you could also just add your own set of parameters.

If you're using the most recent code, though, then rather than adjusting the regtest parameters, you could also just add your own set of parameters.  - if adding new own set of parameters, where am I going to call them? I mean, even a parameter, such as nSubsidyHalvingInterval, doesn't show up anywhere else (like in main.cpp) than in chainparams.cpp only!?

You would have to modify the startup process to recognize some new flag (like -myparams) and select the parameters based on that flag. Then all calls to Params() will return your params.

Unfortunately I can't follow you with modify the startup process, do you mean a flag, like -regtest or -testnet?If so, I searched for them in src but only found out - to my perception - that out of bitcoind.cpp there isn't any call for parameters defined in chainparams.cpp..Could you please give me hints or give me concrete instructions on how to set new set of parameters?

authors: Сергей Баландин


text:
Do all Crypto Coins use the same Wallet Format?
There are many crypto currencies now, BTC, LTC, MTC, Potcoin and so on. Each of these have their own wallet.dat files used by the client software.
My question is: Do all these crypto currencies make use of the same format of wallet.dat file?
pywallet.py can be used to dump the keys from a BTC wallet.dat file.
Can pywallet.py also be used to dump the information from a wallet of an alternate crypto currency like LTC/MTC and so on?

The wallet.dat is a Berkeley DB file.
You can parse it using following command (You need to install Berkeley DB on your unix environement first)
db_dump wallet.dat

I checked for Bitcoin and Litecoin and in both case the wallet.dat was using the same version of Berkeley DB.
VERSION=3
format=bytevalue
database=main
type=btree
db_pagesize=4096
HEADER=END

I haven't try pywallet.py but I guess it should work for all these Bitcoin derived altcoins.


text:
Proper way of using a Mixing Service
I want to use a mixing service and I was wondering what is the right way of using it.
I have some funds in my wallet (associated with a Bitcoin Address).
Should I generate a new address in my bitcoin client (this address would be picked up from my keypool itself right now). And after generating the address, I provide this address as the receiving address (for withdraw) to the mixing service?
Second case. Let's say I want to purchase something online using my bitcoins, like dedicated hosting service or something similar. The merchant wants me to send them the Bitcoins to their bitcoin address, but if I go through the mixing service for this purpose, it would take a very long time and transactions with merchants have to be completed fast.
In cases of mixing services like bitcoinfog, the minimum time interval is 6 hours after which the withdraw process starts.
So, what is the right way of using the mixing service?

Either of these solutions would work.
If you mix it first to a previously unused address or send it directly to the merchant via the service (ignoring the issue of timeouts on a merchant terminal if they have such a feature) the effect is the same.
The only thing to make sure is any change does not go back into an address which has not been via a coin sharing service. This will cause a link-back to your previous transactions.
The easiest way to avoid this is to have two separate wallets, one which is only been mixed and one which has not.

Thanks, could you elaborate your answer a bit? The part which talks about using two different wallets to accomplish this. So, I transfer the amount of BTC I want to mix from the original unmixed wallet to a fresh new wallet. Then, from the fresh wallet, I generate a new receiving address. Transfer the BTC from the fresh wallet to the mixing service and specify the withdraw address as the receiving address I generated using the new wallet. Is that correct?

By two different wallets, I mean for example multibit, 2 seperate wallet files. Generate 100 addresses or the likes in each. One use for regular transactions and use another one for only coins which have been via a coin share. This way any time coins are sent to a change address you know they have all been mixed already and not linking to any service you sent coins directly to. You can switch between wallets seamlessly with multibit.

Thanks but I wanted a method without going for Multibit :) If the mixing service returns the coins to a newly generated address from a new wallet, wouldn't that be anonymous enough as well? I could then use this address for further transactions. So, the original wallet is used only to transfer BTC to the new wallet which then pops them into the mixing service and gets its output. This thing is complicated :D

That is fine. I was assuming you were going to be doing this more than once. I think what your explaining is basically the same thing as what I m suggesting lol.

Step #1: Create a wallet on the clearnet. (We will refer to this as wallet #1)
Step #2: Buy Bitcoins, and send the amount you want to mix to wallet #1.
Step #3: Create a second wallet, this time over the Tor network. (wallet #2)
Step #4: Send your bitcoins from wallet #1 directly to wallet #2.
The reason for this is to add plausible dependability between your clearnet wallet and in-person purchases. If you are ever investigated by law enforcement or the company from which you are buying coins (this happens with Coinbase.com especially), you can reasonably claim that you sent them to someone else who controls wallet #2 (for whatever made-up reason you have in mind as your excuse for your BTC purchase). After that you have no idea/don’t care what that person did with them, nor should anyone expect you to.
Step #5: Create a third wallet, also over the Tor network. (wallet #3).
Step #6: Use Helix Grams mixer (onion link: grams7yngnpr5rzf.onion) and set up your transaction there using the address(s) from wallet #3. It is best to use multiple addresses, and to set random time delays.

I recommend using steps 5 and 6, rather than step 4.  It's better to simply be unknown to snooping organizations than to have plausible deniability.


text:
What is the User Activated Softfork (UASF) proposal? How do its risks compare to hardforks?
The Bitcoin community is abuzz with discussion about shaolinfry's proposal of a UASF to activate SegWit as an alternative to the Version Bits activation. I've seen frequent and extensive discussion of the proposal and especially questions about the risks and advantages of it compared to other methods of softfork activation and hardforks.

What does the UASF proposal entail?
How do its risks compare to other methods of upgrading the protocol?

What does the UASF proposal entail?

The UASF proposal is an extension of BIP9 that allows soft-forks to specify a mandatory activation time. If miners have not started signaling support by this time, they must start to signal. Any blocks not signaling support for the soft-fork after this time are rejected.
BIP148 is an instance of the UASF proposal that implements a UASF for SegWit. The idea is to have the economic majority, users and businesses, run software that forces miners to activate SegWit. If miners do not start signaling for SegWit by the proposed time, their blocks and the bitcoins mined within will be invalid. In this sense, it is a hard-fork for miners, but a soft-fork for most full-node operators.
A soft-fork usually undergoes the IsSuperMajority process, where miners do not start to enforce the new rules until 95% of the last 1000 blocks signal readiness to enforce. This is usually just for coordination, so that miners are in agreement about exactly when the new rules become enforced. Of late, however, miners have been using this process to block the SegWit soft-fork from being enforced at all. Many believe that miners should not be able to block soft-forks, so the UASF was created to remove that ability from miners.

How do its risks compare to other methods of upgrading the protocol?

A UASF may transition to be enforced before miners have updated their software to support it (typically this would be intentional on a miner's part, as the activation date would be chosen very far in advance). In this case, that miner may be mining invalid blocks, according to the rest of the upgraded network. If a large portion of the network has upgraded their software to enforce the signalling for the soft-fork, but a large portion of the miners do not agree to signal for the support of the soft-fork, then a chain fork may occur. Non-mining nodes would see very slow block generation times and the transaction backlog could grow. Mining nodes would produce blocks, and bitcoins within, that are not acknowledged as valid by exchanges and users, rendering their mined bitcoins worthless if they do not upgrade.
This situation would create a stand-off between economic stake-holders and miners. For upgraded nodes, the longer the stand-off continues, the more transactions build up in the backlog without miners mining them. For miners, a chain-split means they are creating bitcoins that exchanges and users will not accept as payment, which is essentially losing money. It is undetermined which group would give-in first and support the other's chain just for the sake of restoring consensus and clearing the transaction backlog. Users and exchanges already cope with low transaction throughput and high block solve times due to normal variance, whereas miners currently have nearly 100% of their blocks accepted by the network. So I suspect the miners would be the first to give in and start signalling support for the soft-fork they don't like.
However, a miner may produce a block which signals support for a soft-fork without actually enforcing the new rules imposed by the soft fork. This may conceal the lack of consensus temporarily, for as long as the produced blocks follow all the rules of the new soft-fork. As soon as a block is produced that does not satisfy the new soft-fork rules but is still valid according to the old pre-soft-fork rules, there would be a chain split with the same stand-off dynamics mentioned before.
UASFs also rely on getting a large portion of the network, especially large economic actors such as exchanges, to upgrade. If this does not happen, and the miners do not start signalling support for the new soft-fork on their own, then the minority of nodes that did upgrade risk forking onto their own chain with no miners on it. This may cause outages of some bitcoin services, but since the bulk of nodes and miners are supporting the growing chain, there would at least be consensus on which chain is valid. Upgraded users would have to downgrade their software to return to consensus with the main chain. In this case, the UASF fails.

But who decides whether a soft-fork has enough consensus to warrant a mandatory activation time? Shaolinfry has this to say on this topic:

There is an implicit assumption in my text, that the decision to deploy a soft fork (regardless of the activation method) is based on a reasonable expectation that users will make use of the new feature. Hashrate signalling is not a vote, but a coordination trigger. Soft forks are backwards compatible and opt-in; so long as they are well written and bug free, users should at worst, be agnostic towards them because they have a choice whether to safely use the new feature or not, without preventing others' enjoyment of the feature. A controversial or unreasonable soft fork would not gain traction and I believe it would be fairly self evident. [Source]

So UASFs could be used to attempt to force controversial or potentially harmful updates, but enforcing the UASF activation time would require the majority of the network to upgrade, so this may be seen as a relatively small risk factor.

In short, UASFs are more risky, but may be deemed necessary when miners refuse to support soft-forks that have the backing of the economic majority.

Good answer overall. I don't think a UASF is akin to a hard-fork for miners. A hard-fork is a relaxation of the ruleset while a soft-fork is a tightening of the ruleset - this is true no matter even in cases like the UASF flag day that can result in a split.

It might not be a hard-fork in the most technical sense, but it's a non-backwards compatible change that requires all miners to update their software or else a chain-split will happen, which is pretty similar.

It's backwards compatible for all non mining nodes that choose not to upgrade.

I would refine (in square brackets) StephenM's answer above as follows:
"For [UASF] upgraded nodes, the longer the stand-off continues, the more transactions build up in the backlog without miners mining them.
For miners, a chain-split means they are creating bitcoins that exchanges and users [ON THE UPGRADED NODES ONLY] will not accept as payment, which is essentially losing money. It is undetermined which group would give-in first and support the other's chain just for the sake of restoring consensus and clearing the transaction backlog."


text:
Where can I find research on wallet fingerprinting?
@raw_avocado asks on Twitter:

I remember reading at some point something about how you can identify
transactions made by specific wallets because they have a specific
fingerprint because of how they construct transactions.
Are there any public stats on this?

Where can we find more information on the unique fingerprints of wallets? Is there a website that tracks this information or maybe an academic paper?

Is this the research article you are thinking about? It's blockchain.com wallet fingerprinting mostly on the basis of feerates by 0xB10C.

oh right, mempool.observer is a great resource for that.


text:
What are the risks of OP_VAULT?
In the past it has been argued that some covenant schemes could be risky. However AFAIK OP_VAULT is a very specific and limited construction.
What are the risks associated with it, if any?

The design of OP_VAULT at the time of writing (April 2023) seems to be in flux and isn't yet finalized. Unlike OP_CTV it is a recursive covenant opcode and the safety of recursive covenants has been discussed extensively on the bitcoin-dev mailing list. It shouldn't pose a network risk or a DoS vector to a node verifying OP_VAULT rules (assuming it was activated on mainnet).
The axis that is more relevant to these more limited covenant opcodes is the utility axis rather than the safety axis i.e. when compared to competing alternatives (SIGHASH_ANYPREVOUT, OP_TLUV, OP_TXHASH and OP_CHECKSIGFROMSTACKVERIFY etc) is this the optimal proposal for enabling this kind of functionality? Burak posted that OP_VAULT functionality could be emulated by other opcodes currently active on Elements.
The design space for opcodes is very large and we can't/shouldn't enable every single possible opcode on mainnet. For more explanation on why see this post. Hence the major risk here is probably that no one would end up using it especially if an alternative superior proposal was activated some time later. And having a slightly inferior proposal active onchain may impact whether that alternative superior proposal ends up getting activated at all. Hence there are lots of factors to consider and assuming we don't want to clog up the consensus rules with lots of unused opcodes we should be extremely selective on what we end up activating on mainnet (ignoring the activation chain split risks that are present with every attempted activation).
There are risks and trade-offs when assessing whether to use a particular vault design that could impact the usage of a covenant opcode like OP_VAULT. Some of the risks of using the Revault vault design are discussed here. However, these aren't systemic risks to the network, just risks to the user of a particular vault design.
edit (September 2023): A tweet thread on OP_VAULT by James O'Beirne is here.

I think the main risk with activating a "feature-specific" opcode, like OP_VAULT, is that users will at some point find out a better way to do "vaults" and the opcode won't support it. By the very nature of softforks, users and developers only really start to use the new feature after it is activated. Thinkers, protocol developers etc might conceptualize use-cases and develop proof-of-concepts, but the truth is that the majority of actual usage comes after activation and with it comes all the creative brain power of people figuring out what they actually want to do.
It's very much possible that when OP_VAULT activates, we realize that there is a sub-optimal aspect to the implementation that now everyone has to stick with. It means that "vaults v2" requires a new version of the opcode and another softfork.
This of course not an answer to "how could the Bitcoin community suffer from the activation of OP_VAULT", but rather "how could the Bitcoin community suffer from the activation of OP_VAULT instead of more general introspection-enabling mechanisms".


text:
Precedence of competing multisig spends
Imagine I want to create a multisig threshold (k-of-n) scheme where a spending transaction with more signatures takes precedence over other spending transactions with less signatures (but in both cases number of signatures is > k). Hence these other spends are invalidated.
For example in a 3-of-9 multisig, a transaction with signatures from 6 keys takes precedence over a transaction with signatures from 3 keys.
I think this can be created used timelocks. Each spending path is encumbered with a timelock such that after some time t only 9-of-9 is valid, after t+1 8-of-9 is also valid, and so on (until 3-of-9 is reached at t+6).
Does this work? Are there better ways to do it?

I'm not sure what you mean by "other spends are invalidated." Its seems like you are describing a scheme where spends using less keys become valid after a timelock.

Related: https://bitcoin.stackexchange.com/questions/116035/how-do-i-set-up-a-time-decay-multisig

Your desired setup sounds very similar to a "Degrading Multisig," and is possible with taproot.
In your example, the 9-of-9 spend would be the key-path spend. You would then create spending conditions for each of the other possible combinations with their appropriate timelocks and place them into a Taptree. Any script path where the timelock has expired is available to be used and more script paths (presumably requiring fewer keys to spend) would become available as time passes. It is worth mentioning that security gets worse over time in the scheme you are describing.
You can see an example of a similar setup here: https://github.com/bitcoinops/taproot-workshop/blob/master/3.1-degrading-multisig-case-study.ipynb. In this example, the key-path is meant to be used by keys that can participate in an interactive MuSig session and the script path allows spending with a separate set of backup keys after a timelock has passed. The script path keys are assumed to be in cold storage and thus unable to participate in an interactive protocol.

As Josie says in his answer a degrading/time decay multisig (also discussed here) seems to be the best solution to what you want.

Imagine I want to create a multisig threshold (k-of-n) scheme where a spending transaction with more signatures takes precedence over other spending transactions with less signatures (but in both cases number of signatures is > k). Hence these other spends are invalidated.

In Bitcoin a transaction is either a valid spend or it isn't. You can have competing transactions (e.g that spend the same outputs from another transaction) but ultimately only one of these competing transactions can be confirmed and included in the blockchain. If a competing transaction is broadcast and propagated whilst the original transaction is still unconfirmed this has zero impact on the validity of the original transaction. They are both potential valid spends until one of them is mined, confirmed and included in a block. Hence it is impossible to enforce "This (valid) transaction should take precedence over this (valid) transaction" other than through the use of transaction fees. You can try to incentivize miners to include one of the competing transactions in a block by increasing the transaction fee of that transaction but there is no guarantee that the lower fee transaction won't get mined.
It is possible that other blockchains using account rather than UTXO models and with more expressive scripting languages could do this but this kind of thing isn't possible with Bitcoin today.


text:
When using a hardware wallet, how do I know that the change address is one that I own?
When signing a transaction on my coldcard, I see a change address that is not listed (at least on the first 30 addresses) on my coldcard. I believe coldcard would only allow me to sign a transaction to a change back address that I own, but how do I know that I own this? It's not listed on the addresses list, maybe possibly because the change back is generated in another way so it does not waste my pre-generated addresses.

Generally payment addresses and change addresses are drawn from separate key derivation chains (cfr. BIP32, which suggests using derivation paths ending in .../0/* for payment addresses and .../1/* for change addresses). There are multiple reasons for this:

Change addresses can function with lower gap limits (number of unused addresses between used ones), as you're always creating the outputs yourself immediately after choosing them, while payment addresses can remain unused as long as a payment is outstanding. That said, in practice, it appears most systems use identical gap limits for both.
Separating the paths means it is possible to reveal to e.g. an auditor your incoming payments without revealing the outgoing ones. While possible, I have not heard about anyone using this possibility in practice.

If the hardware wallet is telling you what the total sent amount is, it means it performed analysis that the change is in fact change. Otherwise it would be treated as outgoing money.


text:
How can I find out who sent me bitcoins?
I had a very unusual situation. I received the bitcoins in my wallet, how can I find out who sent them?
Maybe it was the Creator of bitcoin ? :)

how can I find out who sent them?

Realistically, you cannot. You could see which inputs were used in the transaction that sent you the bitcoins, and attempt to find their owner. But there is no information encoded into the transaction that states who sent it.
If you met someone that claimed they were the one to send the coins to you, then you could ask them to sign a specific message of your choosing, with the private key of one of the transaction's inputs. Whoever sent the coins to you will have access to at least one of those private keys, so they would be able to prove themselves in this way.

thank you, but I don't think I'll find the sender because I've left my wallet address on several websites:(

@Augusta: Remember that Bitcoin is digital cash. You cannot tell who gave you a $5 bill (banknote) just by looking at it. The serial number is, in general, no help. Bitcoin deliberately has similar (though imperfect) properties of (pseudo) anonymity and fungibility.


text:
How to generate sub addresses belonging to one private key
We're creating a platform to buy/sell Bitcoin.
We need to generate a new child address for each customer allowing them to receive Bitcoin. But all incoming Bitcoins should be stored in our main wallet actually.
These are what we have done up to now:

Creating a new wallet using Blockchain.com API using /api/v2/create and receiving an address as 1551SHYQu8CPuRxJagViGkppNZrv2gkfFi
Converting the wallet to HD using /merchant/:guid/enableHD
Receiving the first sub-wallet (xPriv & xPub) if I am not wrong with a new public address 1CLpEvgs9o2mgKN5aS1mPeXGcqXs7fT75F
Send BTC to the address generated in step 3.

We expected that the transaction happened on on the last address as a derived child from the first address should be stored and visible in the main wallet, but by using explorers, we found out that there is not any event on the main address, whereas the transaction on the second one is confirmed.
We may did something wrong, or we might have a misunderstanding about the correct behavior in this purpose.
Your assistant is much appreciated.

Addresses derived by an HD wallet are intentionally not publicly linkable to one-another (that would be obviously terrible for privacy). Your wallet software will know the addresses are related (ie, it derived them all from the same seed), but a casual observer will not.
Accordingly, when you pay some bitcoin to a child address, there is no associated activity involving the parent addresses.

How to generate sub addresses belonging to one private key in blockchain.com API

You cannot. Each address derived by an HD wallet will have a corresponding, unique private key related to it. The master private key for the wallet will not be able to sign and spend any funds stored at child addresses - you need the child private keys to do that.

Thank you @chytrik for the reply.
I hope you know our needs based on the information I've provided in my question. Now, I am sure that we have a problem in our understanding about HD wallets.
May you tell me please what is the usage of HD wallets if the generated addresses can not be associated with the main account?
And what is the best solution regarding to our requirements in the project?

HD wallets are useful in many ways, for example the ability to load an xpub key onto an insecure server in order to generate receiving addresses. Generally, if you're operating a business, each new user can be associated with a new address, helping differentiate payments. To spend those funds you just use the private key for each address, which is generated in parallel on a secure machine. I'd recommend reading through: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki and https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch05.asciidoc, at least

in this way, we can generate normal pub/priv keys too and we should store them somewhere like xpub/xpriv ones. Finally, we have to keep all key pairs and use them separately for transactions. Am I right?


text:
How to getheaders from blockchain?
I have run a full node on linux
now I can run commands with bitcoin-cli like:
bitcoin-cli getbestblockhash

it returns:
0000000000344240308f54ded700542571b3df9efe05fab92e669099e20e0d92

or
bitcoin-cli getblockcount

82273

but I can't know where should I change get block to get headers:
https://bitcoin.org/en/developer-reference#getheaders
I want to get all headers instead of total blocks to have a SVP node.

You can use the command bitcoin-cli getblockheader "hash" ( verbose ) to return a specific block header. For more info: bitcoin-cli help getblockheader

but I can't know where should I change get block to get headers: https://bitcoin.org/en/developer-reference#getheaders
I want to get all headers instead of total blocks to have a SVP node.

The getheaders message referenced in that link is part of the peer-to-peer gossip protocol between nodes, not the command line interface. From that link:

The getheaders message requests a headers message that provides block headers starting from a particular point in the block chain. It allows a peer which has been disconnected or started for the first time to get the headers it hasn’t seen yet.

Thank you, Yes I know about getblockheader command, but I want to have all headers instead of blocks. I have downloaded https://github.com/bitcoin/bitcoin and install it on linux. It works very well but I don't want to download 300GB, As I know SPV download only headers but I can't find any place to change type of message, change from block to header, something like a line to add bitcoin.conf

@HamidNaghipour Bitcoin-core is a full node; there is no configuration options to turn it into a light-verification (SPV) wallet. You can enable pruning mode to trim the datadirectroy size down (to just a few gigs if you so desire), but your machine will still download and validate the whole chain first. If you are looking for an SPV wallet specifically, bitcoin-core is not what you want.


text:
UNIX END TIME January 19, 2038 - Will it affect Timelock nLOCKTIME smart contracts past that date?
So UNIX END TIME is January 19, 2038.

What will happen then to the btc TX that looks at Unixtime for nLOCKTIME transactions?

Will any Locktime transaction past that date, say to 2040 be an issue? Or will blockchain continue adding to the Unix time like there was no end date?

Timestamps in Bitcoin, including block timestamps and nLocktime values, are unsigned 32-bit.
The last possible timestamp is Feb 7th 2106, at 06:28:15 UTC.

That is good to hear that nLocktime will not be affected then. Thankyou


text:
Valid fork in regtest - Change blockchain via RPC?
I've created a regtest network consisting of 2 nodes - node0 & node1.
I'd like to have a fork on the common blockchain and seemingly achieved it by doing so:

nodes start
node0 adds node1 via addnode
node0 generates 1 block with hash 4dac...
node1 generates 1 block with hash 5d8b...
node0 invalidates node0's block with hash 5d8b... via invalidate <hash>
node1 stops
node0 generates 1 block with hash 64f2...
node1 restarts
node1 generates 1 block with hash 5sfg...
node0: getchaintips returns an array with invalidated block's hash 5d8b... with status

Now my questions:
a) How can I achieve a "valid-fork" status in the output of getchaintips for the previously invalidated fork? [SOLVED]
b) Is it possible for a node to "conciously"/via RPC give up its own chain and switch to the competing chain?

Did you had a look at: https://github.com/bitcoin/bitcoin/blob/master/qa/rpc-tests/getchaintips.py?

@JonasSchnelli: Yes i looked at that code but didn't understand much since I'm not familiar with python..but one difference is there between my scenario and the scenario described inside the code: I have subbranches of same lengths and the code describes branches of different lengths..is this the key point?

The longest valid chain is always chosen automatically. Thus the way to make it forcefully switch is using the invalidateblock hidden RPC.

I re-read the Bitcoin Developer Guide and re-read the help getchaintips section:

Each full node in the Bitcoin network independently stores a block chain containing only blocks validated by that node. When several nodes all have the same blocks in their block chain, they are considered to be in consensus. The validation rules these nodes follow to maintain consensus are called consensus rules.

and

Possible values for status:
  [..]
  "valid-fork":This branch is not part of the active chain, but is fully validated
  [..]

For a) So in order to achieve a valid-fork status for a previously invalidated block hash node0 needs to reconsider that very block hash in order to have it fully validated on its copy of blockchain. This can be achieved by reconsiderblock <block hash>.
Note:reconsiderblock apparently "closes" the fork since getchaintips returns the same block hash for the active chain tip for both nodes.
For b) Nothing found out yet.

For b: invalidateblock RPC marks a block as unconditionally invalid. The reconsiderblock RPC wipes this invalid state.

Regarding a) I'm not really familiar how it validates the block, but my guess is no.
as for b) it is possible to give up its own chain of the other chain is the longest valid chain.

Blocks in shorter chains (or invalid chains) are not used for anything. When the bitcoin client switches to another, longer chain, all valid transactions of the blocks inside the shorter chain are re-added to the pool of queued transactions and will be included in another block. The reward for the blocks on the shorter chain will not be present in the longest chain, so they will be practically lost, which is why a network-enforced 100-block maturation time for generations exists.

https://en.bitcoin.it/wiki/Block_chain

For b) You quote "When the bitcoin client switches to another, longer chain, all [...]" - But my question is how one can conciously, e.g. as per a RPC, switch the chain!?

The longest chain is always selected by the wallet software there is no RPC option to force a chain switch.

authors: สมชาย หงส์แดง


text:
What is "trickling" in terms of bitcoin?
In the Bitcoin (0.10.0) source code I'm coming across the term "trickle".
Could someone please give short but accurate explanations on following instances and tell what they're used for?

bool fSendTrickle
bool fTrickleWait
CNode* pnodeTrickle ?

What is the general idea behind "trickling"?

Trickle is a reference to how the node manages announcing other peers addresses.

I think a bit more info could be useful here.


text:
How to access peer's tip of chain?
In case I'm a selfish miner and have successfully forked the blockchain, I'd like to know the state of progress of my honest nodes at any given time - how can I achieve this?
Do peers on separate blockchains exchange information about their progress through data messages?
Let's look at this scenario for a better understanding:
selfish node=s;    honest node=h
s: mine a block#1 (child of genesis block), don't report
h: mine block#2, block#3 publicly
s: mine block#4, block#5 secretly (don't report)
h: mine block#4 publicly
s: get information what block height the honest network is at!?
NOTE:

pindexLastCommonBlock doesn't seem to be helpful since calling its
height would say that last common block is 3, but does not say what
height honest nodes are at.
setInventoryKnown in case of a fork stores all blocks ever mined.

peers on separate blockchains - If by separate blockchains you mean different coins, these peers don't talk to each other at all. If you mean peers working with the same blockchain but at different points in the synchronization process, these peers do exchange data messages.

No by separate blockchains I mean on separate subchains with a common forked block.

I don't see how that's any different from the second situation I posed in my first comment.

Ok if its the same thing as what you mean by node with different sync points, then we talk of the same phenomenon

SPV wallets typically keep track of what the best known block for each of their peers is as well, to make sure they are up to date and can assess the security of their transactions (# of confirmations). The way they do this is to start a counter initialized at the height given in the version message. And then when the node broadcasts a new inv (inventory) message for a block, get that block header, and if it builds on their previous best header, then increment the counter. With this method, you can keep a mapping of nodes to their main chain tips.
Essentially, this is just keeping track of the inv broadcasts form a peer, which is how peers publicly report new blocks.


text:
How to access locally stored inventory data?
I'm looking for objects in the source code of Bitcoin Core that record all block inventories distinguished by their miners - Is there a container that keeps track of blocks on chainActive and stores it to disk?
I'm trying to find analogs for what is defined as private and public branch in the paper about the Selfish Mine Attack.
NOTE:
As I noticed by some tests, vInventoryToSend and setInventoryKnown don't seem to be very helpul in their actual form:
vInventoryToSend temporarily stores only freshly self-mined blocks and setInventoryKnown stores all blocks, no matter if self-mined, received or even outside of chainActive.


text:
Is it possible to detect if flag -txindex is enabled using RPC?
Using JSONRPC, how do I detect if a node has -txindex enabled?

You can use the getindexinfo RPC call to list (and get the status of) all the available indexes since version 0.21 (currently in rc3).
On my local bitcoind with (only) txindex enabled, here is the output:
$ bitcoin-cli getindexinfo
{
  "txindex": {
    "synced": true,
    "best_block_height": 660887
  }
}