text:
Moving 'Sent' Transaction from Default Account
I would like to move a sent transaction from the default account to another account held on the same wallet.
I am using version 0.16 so I still have the depreciated accounts functionality.
I'm not exactly sure how to do this or if it is even possible. I was thinking the 'move' or 'setaccount' commands would do it but I'm not sure how to compile the command.
Any help would be much appreciated.

move a sent transaction?

Yes, move sent transaction to another account.

can you explain what you're trying to achieve, that doesn't really make sense to me. Do you mean reassigning account names: https://bitcoincore.org/en/doc/0.16.3/rpc/wallet/setaccount/

Is it possible to add a comment to a sent transaction after it has been sent?

With the bitcoin core wallet, I don't think so.


text:
Adding Comment on Bitcoin Transaction (After Sent)
Is it possible to add a comment to a bitcoin transaction after it has been sent?

Certainly. It is entirely dependent on the wallet software you are using. Bitcoin transactions do not actually have comments associated with them at all. Any comments or descriptions are local to your wallet software. That means that you can always add a comment to a transaction as it is simply updating an entry in your wallet software.

Thanks Andrew. Are you able to share the bitcoin-cli example on how to add a comment?

There isn't a way to do that with the bitcoin-cli.

Any suggestions on how to do this then? Which client?

The Bitcoin core API has no provision for this.
A specific wallet might have provision for this in its API or through a GUI.

What about curl?

source: Stack Exchange

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

sort: votes


text:
Need help on building transaction with go(lang)
i try to send a transaction to bitcoin testnet for about 3 days now but i can't success... Probably someone can help and give me some example code.
What i try to do:
I'm writing some payment functionality in the stellar network, where people can pay with btc. Therefore i generate a bitcoin address/WIF and save this in my db.
I then please the customer to pay on this address. I check all transactions from the bitcoin network and when i get a payment on this address i want to either move the btc to some other btc-address or refund the amount (minus fee) to the source btc-address.
I'm running a full node (https://hub.docker.com/r/kylemanna/bitcoind/) and checking the transaction works great.
But for the transfers i'm stuck somehow. I'm new to bitcoin, so this might probably be the  reason ...
I'm building the service with go(lang) and using the https://github.com/btcsuite so far. I'm connecting via rpcclient.
The only resources i found on the web for this is:
https://www.thepolyglotdeveloper.com/2018/03/create-sign-bitcoin-transactions-golang/
Till now i tried the following UTXO:
f3a38acecbd9faaaebc8cb8fd88cb535388060f35923b60e6a7f185b4bb35a4f
(https://live.blockcypher.com/btc-testnet/tx/f3a38acecbd9faaaebc8cb8fd88cb535388060f35923b60e6a7f185b4bb35a4f/)
The WIF-String for "n18HgZaBAT3r7PmdLE6jxxHUCQbi65neiQ" is "cNtsnL67rYr3r2nX6vyZrDrBGk4cKbvcMKS6wmfnzRwCCYiA4Soj"
The signed transaction i created so far are all valid and i can paste them into https://live.blockcypher.com/btc-testnet/pushtx/ but i always get an error that there's a missing reference for the transactions. My docker-node returns "Missing inputs".
If someone could give some complete example, on how to create this transaction, i would be very very happy.
Many thanks.

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


text:
Mining in the wallet
Someone said me that I should give him my wallet email and then he will request for the mine from the mining network, after that he asked that you will receive email from that u will get code which u have to send me and then invest your bitcoin wallet with 50$.And after some hours I will get the profit in my wallet. Is this a scam?

If you did not create the bitcoin address to which the $50 must be sent, then most likely yes.

This is 100% a scam, mining does not work in the way this person has described to you. DO NOT EVER give out your password, private keys, seed phrases, login info, etc, to anybody. There is never any need to, anyone asking for that info is almost certainly trying to rob you.

I'm not sure if you are talking about a private key, but if so NEVER give someone else your private key.
Either way, $50 worth of bitcoin doesn't matter to miners.  They just care about hash power.  Account holdings only matter in PoS.
In the end, yes this sounds like a scam

Yes, it is a scam. You do not want to give the private key of your wallet to anyone. Do not deal with this person.


text:
Who gives the block to the miner
Im still making my way into the block-chain world. I have been reading a lot.
I want to know who gives a block to the miners?, then they compete to get the challenge right, whoever gets the challenge right has the privilege to add the block. My confusion is how is a block created in the first place? where does the transaction come to the pool of miners?

I want to know who gives a block to the miners?

Nodes typically give the block (or block template) to the miners. To be even more accurate, typically mining pool software will get the block data from a node, and distribute that to the miners.
getblocktemplate is an RPC call in Bitcoin Core intended to provide the miner with something to mine. It should contain valid transactions assembled as a valid block that just needs the proof of work. See https://bitcoincore.org/en/doc/0.16.2/rpc/mining/getblocktemplate/
getblocktemplate ( TemplateRequest )

If the request parameters include a 'mode' key, that is used to explicitly select between the default 'template' request or a 'proposal'.
It returns data needed to construct a block to work on.
For full specification, see BIPs 22, 23, 9, and 145:
    https://github.com/bitcoin/bips/blob/master/bip-0022.mediawiki
    https://github.com/bitcoin/bips/blob/master/bip-0023.mediawiki
    https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki#getblocktemplate_changes
    https://github.com/bitcoin/bips/blob/master/bip-0145.mediawiki

Arguments:
1. template_request         (json object, optional) A json object in the following spec
     {
       "mode":"template"    (string, optional) This must be set to "template", "proposal" (see BIP 23), or omitted
       "capabilities":[     (array, optional) A list of strings
           "support"          (string) client side supported feature, 'longpoll', 'coinbasetxn', 'coinbasevalue', 'proposal', 'serverlist', 'workid'
           ,...
       ],
       "rules":[            (array, optional) A list of strings
           "support"          (string) client side supported softfork deployment
           ,...
       ]
     }

Result:
{
  "version" : n,                    (numeric) The preferred block version
  "rules" : [ "rulename", ... ],    (array of strings) specific block rules that are to be enforced
  "vbavailable" : {                 (json object) set of pending, supported versionbit (BIP 9) softfork deployments
      "rulename" : bitnumber          (numeric) identifies the bit number as indicating acceptance and readiness for the named softfork rule
      ,...
  },
  "vbrequired" : n,                 (numeric) bit mask of versionbits the server requires set in submissions
  "previousblockhash" : "xxxx",     (string) The hash of current highest block
  "transactions" : [                (array) contents of non-coinbase transactions that should be included in the next block
      {
         "data" : "xxxx",             (string) transaction data encoded in hexadecimal (byte-for-byte)
         "txid" : "xxxx",             (string) transaction id encoded in little-endian hexadecimal
         "hash" : "xxxx",             (string) hash encoded in little-endian hexadecimal (including witness data)
         "depends" : [                (array) array of numbers
             n                          (numeric) transactions before this one (by 1-based index in 'transactions' list) that must be present in the final block if this one is
             ,...
         ],
         "fee": n,                    (numeric) difference in value between transaction inputs and outputs (in satoshis); for coinbase transactions, this is a negative Number of the total collected block fees (ie, not including the block subsidy); if key is not present, fee is unknown and clients MUST NOT assume there isn't one
         "sigops" : n,                (numeric) total SigOps cost, as counted for purposes of block limits; if key is not present, sigop cost is unknown and clients MUST NOT assume it is zero
         "weight" : n,                (numeric) total transaction weight, as counted for purposes of block limits
         "required" : true|false      (boolean) if provided and true, this transaction must be in the final block
      }
      ,...
  ],
  "coinbaseaux" : {                 (json object) data that should be included in the coinbase's scriptSig content
      "flags" : "xx"                  (string) key name is to be ignored, and value included in scriptSig
  },
  "coinbasevalue" : n,              (numeric) maximum allowable input to coinbase transaction, including the generation award and transaction fees (in satoshis)
  "coinbasetxn" : { ... },          (json object) information for coinbase transaction
  "target" : "xxxx",                (string) The hash target
  "mintime" : xxx,                  (numeric) The minimum timestamp appropriate for next block time in seconds since epoch (Jan 1 1970 GMT)
  "mutable" : [                     (array of string) list of ways the block template may be changed
     "value"                          (string) A way the block template may be changed, e.g. 'time', 'transactions', 'prevblock'
     ,...
  ],
  "noncerange" : "00000000ffffffff",(string) A range of valid nonces
  "sigoplimit" : n,                 (numeric) limit of sigops in blocks
  "sizelimit" : n,                  (numeric) limit of block size
  "weightlimit" : n,                (numeric) limit of block weight
  "curtime" : ttt,                  (numeric) current timestamp in seconds since epoch (Jan 1 1970 GMT)
  "bits" : "xxxxxxxx",              (string) compressed target of next block
  "height" : n                      (numeric) The height of the next block
}

Examples:
> bitcoin-cli getblocktemplate
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getblocktemplate", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/

Nobody gives the block, the miner comes up with it. Think of it as designing a mansion. The possibilities are endless: it can even be an empty block without transactions (there is no mansion, just a garden shed). It only needs to be valid in two ways: no conflicting transactions (the design is physically possible to build) and it has to be cryptographically secured (you have to go through the legal bureaucracy before the construction may begin). In bitcoin world, only the last part takes any significant time, and it doesn't depend on your design at all, it's pure luck.
Only certain blocks are valid, so miners have to spend time manipulating the contents of the block until it satisfies the target hash. The transactions however are merely suggestions, the miner has the complete authority and can "build" whatever they want. When they work on the block to make it meet the difficulty standard, they only "manipulate" the parts that don't matter.

THis answer would be better if it also answered the part of the question where Fahd asked "[how] does the transaction come to the pool of miners?" and explained what incentive there is for miners to include transactions in blocks rather than mining empty blocks.


text:
I lost my bitcoin wallet
I have an address in an investment site I did some investments. Want to withdraw right now, but I can not remember what wallet that address is linked to. Can I trace an address to a wallet?

With only the bitcoin address, there is no way to discern which wallet was used.
Bitcoin addresses do not contain this sort of information, if they did it would be detrimental to user privacy and security.

Thanks very much. It there fore mean I will have to forget about that address and wallet.

That may be the case if you have no other way to trace it. Hopefully you can change your withdrawal address without much trouble. If this answer helped, please remember to mark it as accepted :)


text:
Are there public RPC node providers?
Are there public RPC node providers similar to Alchemy or Ankr, but for Bitcoin?
I just want to query basic block data and so on without having to manage my own full node. Security does not matter in my use case.

You can get one with Chainstack. 3M calls on the free developer plan per month.

Thank you! Exactly what I was looking for.

You can check out the RPC by NodeReal. Under their Free-tier subscription, you can enjoy up to 100M Compute Units.


text:
Transfer wallet coins without syncing
I have not synced my wallet in 2 years and I would like to cash out my coins without syncing for 2 weeks or more. I do have wallet backup. Is it possible to use backup wallet somewhere online so my coins are available instantly?

Still not fully clear as I understand I will need passphrase. I was hoping to import my wallet.dat file into online service, but I guess this is not possible.


text:
When update mining difficulty, Is the timespan of the past 2016 blocks approximated value?
I know how to calculate difficulty, and I know it is increased or decreased by checking the timespan of the past 2016 blocks.
and I found actual code for calculating timespan: https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp#L55
actual_timespan = last_block->get_timestamp() - first_block->get_timestamp()

But, as I know timestamp in block is not the exact time of the mining:
https://en.bitcoin.it/wiki/Block_timestamp
So, the timespan which is used to calculate the next difficulty is not the exact timespan but approximate value. Am I right?

It is impossible to know that actual timespan due to network delays, malicious miner behavior, being offline, etc. The target readjustment just uses the closest thing it can get to the actual timespan which is the difference in the timestamps. However those timestamps can be faked as well, so it is just an estimate.

You are right. but I just want to make sure that timestamp is also very inaccurate.
not only because of network delays, malicious behavior, offline, but also because of choosing rules of timestamp

Yes, the network rules permit blocks to be created with timestamps up to two hours in the future, and generally up to one hour in the past (it has to be after the median of the timestamps of the 11 past blocks).


text:
Bitcoin RPC createrawtransaction parse error
I try to create a raw transaction using the Bitcoin Core RPC through curl.
Python script:
import requests

data = '{"jsonrpc":"2.0","id":"curltext","method":"createrawtransaction", "params": [\'[{"txid":"bffa31485fe5bfbb7e86463ff6c7ee4f084936d54d0471fba7763538e7fd0aa6","vout":0, "sequence":1}]\' \'{"2Mt1FE9NVXP7fRYuPEZBHrFgoCEc4TGb2ZY":0.01}\']}'
print(data)
rawtx = requests.post("http://user:pass@127.0.0.1:18443", data=data).text
print(rawtx)

Output error:
{"jsonrpc":"2.0","id":"curltext","method":"createrawtransaction", "params": ['[{"txid":"bffa31485fe5bfbb7e86463ff6c7ee4f084936d54d0471fba7763538e7fd0aa6","vout":0, "sequence":1}]' '{"2Mt1FE9NVXP7fRYuPEZBHrFgoCEc4TGb2ZY":0.01}']}
{'result': None, 'error': {'code': -32700, 'message': 'Parse error'}, 'id': None}

I've tried escaping in multiple ways, but can't get it working.
Bitcoin CLI command:
bitcoin-cli -testnet createrawtransaction '[{"txid":"bffa31485fe5bfbb7e86463ff6c7ee4f084936d54d0471fba7763538e7fd0aa6","vout":0, "sequence":1}]' '{"2Mt1FE9NVXP7fRYuPEZBHrFgoCEc4TGb2ZY":0.01}'

Expected output (tx hex):
0200000001a60afde7383576a7fb71044dd53649084feec7f63f46867ebbbfe55f4831fabf0000000000010000000140420f000000000017a9140853562996d502a0abe2538657e5bf7bb261b6868700000000

Your data string isn't correctly formatted JSON. This should be the correct version:
data = '{"jsonrpc":"2.0","id":"curltext","method":"createrawtransaction", "params": [[{"txid":"bffa31485fe5bfbb7e86463ff6c7ee4f084936d54d0471fba7763538e7fd0aa6","vout":0,"sequence":1}],[{"2Mt1FE9NVXP7fRYuPEZBHrFgoCEc4TGb2ZY":0.01}]]}'


text:
How can block time and block size be fixed when transaction volume is constantly increasing?
As I understand it the network rejects blocks over 1MB, and block hash difficulty is set after each block is created as to keep the block time close to 10min.
But if people are constantly joining the network, and the rate at which transactions are sent to the network are constantly rising, then eventually more than 1MB of transactions will be added to the network every 10min.
What happens as the transaction rate approaches and passes 1MB per 10min? Is this a valid issue?

When transactions are received, nodes will hold those transactions in memory (the mempool) whilst mining software attempts to mine a new block. A miner will try to fit as many transactions into a block as they can, so as to earn more fees if they successfully mine a block.
If there are more transactions than will fit in the block, the miner must filter them so as to include enough while keeping under the block size limit. The filtering method typically used is to order transactions by fees paid, and include the highest fee transactions, because this results it the biggest payout if they are successful at mining the block.
Any transactions which were left in the mempool will then be candidates for adding to the next block in the chain, but will be placed under the same filter whilst additional transactions are coming in from the network also. This means that a transaction only paying low fees may be in the mempool for a long time because they are deprioritized over transactions which are paying more.
This creates a fee market for block space. People who require their transactions to be processed in a timely manner - the next few blocks, will pay a higher transaction fee which will promote them to the top of the queue, whereas people who have no urgency for their transactions to be processed will pay a lower fee and be willing to wait until the size of the mempool is reduced.
As transaction volume increases due to more demand, people must either pay more fees, or utilize new technologies to reduce the size requirements of their transactions in order to pay less in fees. Some techniques for achieving this are batching transactions, using payment channels (like the Lightning Network), using sidechains, and using future improvements to the bitcoin itself, which will allow for signature aggregation, and removal of unevaluated branches of bitcoin script.

As I understand it the network rejects blocks over 1MB, and block hash difficulty is set after each block is created as to keep the block time close to 10min.

The difficulty is adjusted every 2016 blocks (approx 2 weeks), by taking into account the blocks created over that period. Blocks are not necessarily every 10 minutes, because it is a random process of finding a valid hash which is under the target value, and can range from seconds to an hour or more. It averages to approximatetly 10 minutes over extended periods of time due to the regular difficulty adjustment.


text:
Will g'root be included in the Taproot soft-fork?
G'root, which I understands as generalised Taproot, was announced a year and a half ago. I'm wondering what the development is on it and if it is part of the taproot softfork.

It is not part of the BIP drafts we're working on for Taproot, and there has not been any development on it apart from publishing the basic idea.
The reason is simply that there are far too many ideas to include all at once; ultimately everything boils down to costs/benefits, and I think just G'root is only marginally useful. And softforks are more than a technical process: we don't need to just propose a technical improvement, but also find adoption for it. The more complex the ideas involved are, the harder the latter becomes.
As I explained on the ML a while ago, I think that G'root does have actual tangible benefits when combined with cross-input aggregation. We deliberately chose to not include that in the current taproot proposal as it interacts in complicated ways with OP_SUCCESS, but perhaps a future change that includes both is possible.


text:
Would a Schnorr PubKey be a different length than a Taproot PubKey like P2WPKH and P2WSH?
A P2WPKH PubKey is shorter than a P2WSH PubKey. Would this also be the case that a Taproot PubKey is larger than a Schnorr PubKey?
If so, wouldn't people be incentivised to use the Schnorr PubKey and as a result Taproot would be less fungible?

A P2WPKH PubKey is shorter than a P2WSH PubKey.

No, not quite. A P2WPKH address is shorter than a P2WSH address. The addresses are both based on a hash of the underlying witness program (i.e. the locking conditions of the output). In the case of Pay to Witness Public Key Hash (P2WPKH) the witness program contains only the public key. On the other hand, Pay to Witness Script Hash (P2WSH) doesn't have a public key, its witness program consists of a witness script. P2WPKH and P2WSH addresses differ in length, because the hash for P2WPKH is a RIPEMD-160 hash which produces a digest of 20 byte (160 bit), while the hash for P2WSH is a SHA-256d hash which produces a 32 byte (256 bit) digest. Thus, the address for P2WSH simply has to encode 12 bytes more data and is that much longer.
Regarding Taproot and Schnorr, the outputs are actually indistinguishable, either commits the funds to a public key. In fact, if the spender doesn't make use of a script path (one of the scripts in a leaf of the tree), but spends the output using the key path, they remain indistinguishable even at spending time.
So, all segwit v1 outputs are always the same length, while the inputs may differ in size depending on how they got spent. They aren't categorized as two different output types, they are all categorized as Pay to Taproot (P2TR). Since the encoding used for public keys in P2TR is also 32 bytes, P2TR outputs end up being the same length as P2WSH outputs: 43 bytes.


text:
Why do my 'sign message' not work on Bitcoin core
If I choose a freshly generated address in Core, and I then choose to sign a message with it, it returns the error message "The entered address does not refer to a key".
Why is this? There should definitely be a key considering that it's an address generated by my seed. It is also the correct address as I checked it multiple times.

Addresses that start with bc1, called Bech32 addresses, can't be used to sign messages, at least for now. It might change in the future.


text:
Is a privacy preserving coin mixer possible on Liquid?
My thoughts:
Liquid uses confidential asset and tx. Therefore the asset type and amount is hiding from chain analysis. However the utxo's still carry history. This history could potentially lead chain analysers to form educated guesses of the assets. This would be far more difficult if a coinjoin mix (batching really) had occured. Coinjoins (batching) with confidential assets and tx would be extremely powerful.
My guestion:
If a 3rd party gathered people's txs and batched them into one single tx. Would this 3rd party be able to see every input and output's asset type and amount? Or is there some fancy crypto where the 3rd can construct the tx without knowing any of that?

In the following I focus on Confidential Transactions (instead of the extension Confidential Assets) for simplicity, but all of what I say is also true for Confidential Assets.
Yes, it's possible to use cryptographic protocols to organize the CoinJoin transaction in a privacy-preserving manner. The ValueShuffle protocol is designed for exactly this purpose.
ValueShuffle indeed makes sure that no third party (e.g., a server facilitating the CoinJoin) learns the involved amounts (or assets). But its privacy guarantees go beyond this requirement: In a nutshell, ValueShuffle makes sure that the amounts of your inputs and output, and the relationship between inputs and output remain private not only to third parties but also to the other the participants of the CoinJoin.
See the ValueShuffle paper for all the details and limitations. Disclaimer: I'm one of the authors.
Your intuition that CoinJoin and Confidential Transactions are a good match is correct.
More concretely, we can exploit two important synergies.

If we have Confidential Transactions, CoinJoins with different output amounts are suddenly possible. This eliminates one of the major restrictions of CoinJoin in practice.
The combination of CoinJoin and Confidential Transaction makes it possible to mix multiple payments instead of merely mixing self-sends (if the payer additionally has a mechanism to get more than one possible address of the payee). As a result, you can mix and pay with your coins in a single transaction. This is much better than CoinJoins without Confidential Transactions, where you first need to perform a mixing transaction and only after mixing you can perform an actual payment in a second transaction. This means that CoinJoining your payments will actually be cheaper (in terms of blockchain space and thus transaction fees) than performing payments individual. This provides a great incentive for doing CoinJoins. This is remarkable because privacy usually comes at a cost -- but in a scenario where Confidential Transactions are already available, CoinJoin comes with a discount.

My talk at Scaling Bitcoin 2017 provides a more detailed explanation on the advantages of combining CoinJoin and Confidential Transactions.


text:
Could OFAC create a soft fork?
If OFAC demanded that no US entity build on top of a block with a sanctioned TX included, would it cause a soft fork?

I think you meant a hard fork.

No, it would be a soft fork. A soft fork means the rules become stricter, whereas a hard fork widens them. An OFAC-compliant consensus-valid block would still be considered valid by nodes that are not aware of OFAC.

The term "soft fork" is a shorthand for "soft forking consensus rule change". One aspect of such a consensus rule is miner enforcement of the new rule, but miners on their own just deciding to enforce a rule without the rest of the network going along with it is not a rule change - it's just censorship. The distinction being that it can be reverted: if miners stop enforcing this rule, or if those miners get replaced by non-enforcing ones, the change is reverted.
Thus, the real question is whether validation nodes go along with it too.

If a minority of the hashrate enforces OFAC (which includes refusing to build on top of non-OFAC blocks or their descendants), but nodes do not adopt the change, then a minority OFAC chain will appear, which is just miners choosing to make themselves irrelevant, as this minority chain will be ignored by everyone else. This is not a rule change, as transactions are unaffected by it entirely.
If a minority of the hashrate enforces OFAC, and some (or all) economically relevant nodes go along with it in the form of a soft-forking consensus rule change, then an actual soft forking rule change happens: two currencies will appear, an OFAC and a non-OFAC one, with possibly independent exchange rates between them. The nodes that adopted the OFAC rule now see their transactions restricted to being OFAC compliant.
If a majority of the hashrates enforces OFAC, but nodes do not adopt any rule change, there will only be a single OFAC-compliant chain, but only as long as this OFAC-hashrate-majority lasts. When the miners stop enforcing this rule, or they get replaced by other miners who don't, the enforcement goes away with it. This is not a rule change, but it does mean a miner-enforced censorship even to nodes who don't opt into OFAC-compliance, for as long as it lasts.
If a majority of the hashrate enforces OFAC, and a significant portion of ecnomically-relevant nodes do too, then it is a true soft-forking change, which results in OFAC becoming the rule of the network, for everyone. It's possible an active further fork appears that rejects this OFAC chain, but there would need to be an active choice by non-OFAC nodes and miners to go this route.

The only cases in which transactions are permanently affected by such a rule change is when economically relevant nodes also enforce OFAC-compliance. Any situation in which it's just enforced by miners is temporary, or irrelevant.
Also note that in order to speak about OFAC-compliance as a consensus rule change, it must be exactly defined what this means. Arguably, any change to the OFAC sanction list would be a new consensus rule, with again forking risk. Removing an address or other criteria from the list, if previously enforced by the network, would arguably be a hard fork, where even a majority enforcing it could lead to two chains.

Since OFAC compliance means a strict tightening of the rules, this would indeed be a soft fork by definition. Whether or not this soft fork leads to an actual chain split depends on how much hash rate enforces OFAC compliance.
If a majority of hash rate is OFAC compliant, there should not be a chain split because the OFAC compliant blocks are valid for non-OFAC miners too, so everyone agrees on what the most PoW chain is. If OFAC hash rate is less than the majority, there would likely be a chain split since the non-OFAC compliant chaintip grows larger than the OFAC compliant chaintip, and the OFAC miners would reject the non-OFAC chaintip.
See for example this related question: Why is a softfork unable to divide the network?


text:
How many weight units does an input use?
What is the weight unit cost of an input? And can you batch/aggregate the inputs or is it linearly growth when you add more inputs to a tx?

The weight of a single input in a transaction always uses:

32 bytes to reference the outpoint id (hash)
4 bytes to reference the outpoint index

Then, if the outpoint is a non-segwit p2pkh output the scriptSig uses:

1 byte to denote the scriptSig size
1 byte to denote the signature size
71 bytes (on average) for the signature
1 byte to denote the public key size
33 bytes for the public key

In total this makes 143 bytes (on average) to reference a non-segwit p2pkh output with your spending transaction.
For segwit p2sh nested p2pkh outputs, the scriptSig uses instead:

1 byte to denote the scriptSig size
1 byte to denote the witness version (0x00)
1 byte to denote the public key hash size
20 bytes for the public key hash

Further, the witnessScript will use the same amount of bytes as the scriptSig for spending non-witness p2pkh outpoints. However, the witnessScript only counts with a quarter to the total weight.
Therefore a segwit p2sh nested input has a weight contribution of 59 bytes + (107)/4 bytes = 86 bytes on average.

What is the weight unit cost of an input?

2 things affect the weight of a tx, the total number of bytes , and the total bytes minus witness data.
Transaction Weight = Base transaction size * 3 + Total transaction size, where
Base transaction size is the size of the transaction serialised with the witness data stripped.
Total transaction size is the transaction size in bytes serialized as described in BIP144, including base data and witness data.
See BIP141

Can you batch/aggregate the inputs or is it linearly growth when you
  add more inputs to a tx?

You can't batch inputs, but you can combine them and send them back to yourself first in a larger amount, but that requires an additional transaction. Probably the best you can do now is to use a segwit address to receive funds so when you go to spend the inputs, the witness data lowers the weight of each input.

And to address OP's specific question, yes, this means that transaction size grows linearly with the number of inputs.

Thank you for the answer, I am however still wondering how heavy an input is?

It depends on the scriptSig, see https://bitcoin.stackexchange.com/questions/68811/what-is-the-absolute-smallest-size-of-the-data-bytes-that-a-blockchain-transac and https://en.bitcoin.it/wiki/Transaction#General_format_.28inside_a_block.29_of_each_input_of_a_transaction_-_Txin


text:
Would a dual-funded channel be a single UTXO?
Would a dual-funded channel be a single tx? The peers would cooperatively create a single tx with at least 1 input each. Is this correctly understood?

Yes, this is correct: a dual funded lightning channel is still represented by a single UTXO.
Generally, we would expect each participant to contribute at least one input to the transaction that creates the dual-funded channel (each participant may also thus end up with a newly created change UTXO as well). This method allows two participants to interact trustlessly to create a dual funded channel.
Perhaps worth mentioning: with a slightly broader definition of ‘dual-funded’, we can imagine ways to create a dual-funded channel, without requiring inputs from both parties. These methods may require more trust between parties than the trustless setup mentioned above, but they may be of interest anyways. Examples:

two parties share ownership of the BTC stored in a certain UTXO, and decide to open a channel using it as the only input
one party contributes a UTXO, while the other party makes an external payment to them. The initial channel balance is then split accordingly, to reflect this payment.
one party contributes a UTXO, while the other party makes an on-chain payment to them. As above, the initial channel balance is then split accordingly. This could be done atomically, which means participants will not need to trust each other. See: splicing in / out of channels.

Those are just a few examples off the top of my head. I’m sure there are other ways to accomplish dual-funding as well.


text:
Can a Seed be Linked Across Two Multisig Wallets?
Consider two multisig wallets, Wallet A and Wallet B, both with a 2-of-3 signing scheme:
Wallet A consists of seeds A, B, and C.
Wallet B consists of seeds B, C, and D.
Now, let's create two transactions:
Transaction 1 is a spend from Wallet A, signed by seeds B and C.
Transaction 2 is a spend from Wallet B, also signed by seeds B and C.
Question:
Will the use of the same seeds in different wallets inherently link these wallets, and therefore, the transactions? How does this affect the privacy and security of the wallets involved?


text:
What are the incentives for miners to include a RSK merge-mining block hash in the coinbase?
The RSK blockchain is merge-mined with a block time of around 30 sek. Blocks are produced when bitcoin miners create valid block headers within the target. The RSK difficulty is far lower than bitcoin's. That means that valid hashes for the bitcoin blockchain are always valid on RSK but even invalid hashes for the bitcoin blockchain are sometimes valid on RSK. When the hash satisfies both RSK and bitcoin's difficulty, miners often include an RSK-tagged output in the coinbase.
The above is my understanding of RSK's merge-mining. My question is why would a bitcoin miner use precious block space for the RSK-tagged output in the coinbase?
My reasoning is that a RSK block is valid as long as the header satisfies the target difficulty whether or not it's a valid bitcoin block as well.
My incomplete knowledge is based (& my curiosity sparked) on this https://blog.rsk.co/noticia/rsk-bitcoin-merge-mining-is-here-to-stay/

The advantages would be receiving RSK sidechain fees on the RSK-mined transactions.
The disadvantages would be the logistic overhead of running an RSK node, the latency introduced by querying it for block mining, and the opportunity cost of space the sidechain commitment that now can't be used for transactions.
(note that I'm not an expert on RSK at all, and this answer is mostly based on generic understanding of sidechains)


text:
Will future softforks decrease fungibility?
In potential future softforks e.g. anyprevout or op_ctv, will it be transparent that a transaction uses this newly added feature? Or will it be hiding in a Taproot script and therefore hidden behind a single Schnoor signature?
The question basically comes down to: will potential users of future features leave a clear fingerprint on the blockchain?

Are you specifically asking about these proposed changes, or in general whether softforks do this? The answer is probably highly dependent on the specifics, and on how/what they end up being used for by the ecosystem.

I was specifically asking about those proposed changes or other new op codes

Everything that is "hidden" in a Taproot script will still be revealed whenever it is used. They only remain hidden as long as the "key path" is used (which means the hidden script with whatever new opcodes it might contain is not used and might as well not have ever existed in the first place).

I disagree with the notion that because it's not revealed it might as well not have existed in the first place. The existance of a script branch provides the ability to use that branch, and that may be enough to alter behavior of counterparties, or provide unlikely but necessary escape valves. E.g. in a 2-of-3, 2 of the 3 parties may be almost always available, so that branch is almost always used (hopefully key path), but that doesn't remove the need for branches with the 3rd party.

I agree with that, I was just trying to be very concrete with what the chain will actually see in case of a key path spend. The chain will never know about the hidden scripts.

Yes, I wasn't disagreeing with the overall point you're making here; just pointing out that seen in isolation, it can be misinterpreted.


text:
Are Bulletproofs fully implemented into liquid?
Blockstream themselves released a paper in 2018 about a more efficient range proof and Calles IT Bulletproofs. I'm wondering if it is already fully integrated into the liquid sidechain?

No, the Liquid system isn't using Bulletproofs yet.
The code has been written to use them, but switching over will require more review, and a hardfork upgrade once deployed.


text:
What are "leaf versions" in Taproot?
What are "leaf versions", when do you upgrade a version, how many versions are there and how do they differ from segwit versions?

SegWit introduced versioned witness programs. When satisfying a script to spend coins you need to provide a redeem script consisting of a version byte and a witness program. The version introduced with SegWit was version 0 (zero).
The Taproot proposal uses this SegWit versioning system by introducing spending rules for version 1. The witness program to satisfy a Taproot spend will be version 1.
The Taproot proposal also introduces a new versioning system in addition to SegWit versions called leaf versions. Each leaf of a Taproot tree will have its own leaf version. This is a version for spending rules from that particular leaf. The leaf version introduced with the Taproot proposal is version 0.
So in answer to your question there is just one leaf version with the Taproot proposal and a new SegWit version (to make two SegWit versions in total). The versions are there for future upgrades and as a user you do not need to upgrade anything like you might say upgrade the "version" of your Bitcoin Core software.
Remember that Taproot is still a proposal at this stage (July 2020) and so at the current time SegWit version 1 and leaf versions are not relevant to any transactions you might make on the Bitcoin network.
[darosior edit: There are 41 possible leaf versions (including version zero) for future upgrades as outlined in BIP-Taproot]

Maybe worth mentioning that there are 41 possible leaf versions: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-7 .

Where do you get 41 from? The BIP refers to 32 leaf versions satisfying those constraints?

There are 32 even leaf versions between 0xc0 and 0xfe, to which we add the 9 values 0x66, 0x7e, 0x80, 0x84, 0x96, 0x98, 0xba, 0xbc, 0xbe.

Sorry I can't read ;)

To add to Michael Folkson's answer, a question one may have is what the differences are between witness versions and leaf versions. Why do we need both?

Leaf versions are not revealed until an output is spent, and thus is not known in general to the payer (who is only given an address). For native witness outputs, the witness version is visible from the the BIP173 address.
Leaf versions do not need to be the same for every script branch. This means that if you have an output that can spent either using an old script, or in rare cases using a fancy new script that needs a new version, the fact that you're using this new version in the first place is not revealed to the network unless it actually needs to be used.
Leaf versions are cheaper, as they are only revealed in witness data (which is discounted by a factor 4 per BIP141). Witness versions are revealed in scriptPubKeys (or scriptSigs for P2SH wrapped ones).
The namespace of leaf versions is less restrictive (there are ~40 of them, while only 17 witness versions).
Leaf versions can be used to change script semantics, but are restricted to a Taproot structure. Witness versions can change anything, including the taproot structure.

In general, witness versions seem more appropriate for changes to the "structure" of spending conditions (taproot, graftroot, cross-input aggregation, ...), while leaf versions are more for changes to the execution rules of individual scripts.
See What are the different upgradeability features in the BIP-Taproot (BIP 341) proposal? for information on more extensibility features in taproot.


text:
Could you open a lightning channel in a confidential transaction?
On an elements sidechain (e.g. liquid) could you open a lightning channel with a confidential transaction.
You could probably open a payment channel but could the channel 'speak' to other channels?
Or is lightning network possible on liquid but only in unblinded transactions?

Short answer: yes.
However that depends on the question if liquid supports segwit and creation of a lightning network. I have not looked at the details of liquid but I believe it does.
The lightning network protocol itself is pretty agnostic to the underlaying blockchain. If you look at the channel announcement messages defined in BOLT7 you will see that every message has the following data fields
[64:node_signature_1]
[64:node_signature_2]
[64:bitcoin_signature_1]
[64:bitcoin_signature_2]
[2:len]
[len:features]
[32:chain_hash]
[8:short_channel_id]
[33:node_id_1]
[33:node_id_2]
[33:bitcoin_key_1]
[33:bitcoin_key_2]

in particular the 32 Byte field [32:chain_hash] is supposed to state the hash of the genesis block (which could be the genesis block of the liquid network). In this way payments can be routed through channels supporting different assets (Bitcoin, litecoin, ...). I don't see any reason why liquid would not be supported.
Actually liquid would make more sense than other assets as 1 LBTC should still be the same value as one BTC. As for varying assets there is an issue pointed out by ZmnSCPxj last december regarding the problem with switching the asset during the routing process.

If amount is hidden in a confidential transaction, how would one discover channel capacity, which is not sent in a channel_announcement?

Liquid indeed support segwit transactions (being based on Elements, Blockstream's experimental platform, which was used to test and design the segregated witness proposal before porting it to Bitcoin), so there is no problem in that regard.
The amount is indeed a more difficult issue. Of course you could selectively unblind the funding transaction in order to prove to others in the gossip that you have a given capacity in the channel, but then why use CT in the first place? That being said it would still be sensible for unannounced channels.


text:
How can i get in touch with a miner
Please can someone help me get in touch with a miner, i am trying to recover my bch sent to a segwit btc address.

I'm voting to close this question as off-topic because bitcoin.SE is not a social networking site. You may want to search for 'bitcoin mining pools' and contact one that seems reputable to you.

If you want to ask in general how to go about solving your problem, you can ask a new question, but you'll need to include more details.

See https://bch.btc.com/docs/help/bch_segwit_recovery for example. I've no idea if they are trustworthy.


text:
Is there a "print to file" parameter or its equivalent for bitcoin-cli; so that results from the daemon are recorded
Is there any way to "print to file" the queried results of the bitcoin-cli. This would be most helpful in my basic cross platform integration of a program I am making with QB64.

Can't you just redirect the output to a file? bitcoin-cli getblockchaininfo > out.txt

I'm voting to close this question as off-topic because it is really about programming in a variant of Quick-Basic, specifically how in QuickBasic to capture the STDOUT of an external program run in a shell statement. See https://stackoverflow.com/questions/41305926/how-to-pipe-stdout-and-stdin-to-qbasic-program.


text:
How to create random address from dogecoin?
It's about dogecoin. I want to make a random address everytime my customer want to give me some donation. It's just like i have multiple address that point to my main address wallet, how to that?
For example my main address is
Drpwpskxxxxxxxxx
And evertytime my members want to give donation they have different address to pay but the coin will come to my main wallet.

Each address is an individual address. You can have multiple addresses in one wallet, but you cannot have multiple addresses pointing to the same key.
Whatever wallet system you are using should have an option to generate new addresses, either as part of an HD wallet or as individual keys. You should be able to use that to generate new addresses as required.
Remember to backup the wallet each time you generate an address if it is not an HD wallet, or remember to backup your seed words if it is.

https://github.com/coinables/Simple-Barebone-Bitcoin-Paywall, i tried to follow this tutorial. But i couldn't find my xPub for my dogecoin wallet, i'm using coinomi wallet


text:
how and when does block and transaction validations take place?
I have a couple of questions and will try to explain them here.
So, let's say we have 4 nodes in the whole network.

one of the nodes (node A) took transactions from pool. before they put it into a candidate block, they first validate each transaction, right ? if so, i guess they check balance and signature. Anything else ?  and if all good, they put each valid transactions into a candidate block and after that, they start mining this block... I guess unvalid transactions disappear or something..

Let's say node A mined the block the quickest. It put the block into its ledger and also shared this block to other nodes so they can add it to their own ledger too.  I know that other nodes won't just add it to the ledger until they confirm that this new block was really mined(will take the hash of the header and check if it's below current). Is this correct ? if so, Then, question is, will they also conduct a validation for each transaction from this block ? if yes - why ? if no - why ?

If I make 2 transactions one after another, even though I only have balance for only one transaction, those 2 will go to pool first. and I guess, when my node checks validation of transactions before putting it into a candidate block, they will see that whichever they check first is valid, and second one is not valid anymore since they already have checked the first one. Right ?

I've been wondering the same. Every tutorial emphasizes how pow hashing works and says little about how tx are actually validated..

Generally each transaction is validated when it is added to the mempool of the node. This happens when the node first sees the transaction, it doesn't wait til it is added to a candidate block for mining. The candidate block for mining would be formed out of the transactions already in the mempool - those which have already been validated by the node.
If another node receives a block then yes, it will validate the proof of work and other factors such as the timestamp, and it will also validate each transaction in the block that it hasn't seen before. The ones it has seen before will simply be removed from its mempool and do not need to be re-validated.
Re 3., nodes will not accept two conflicting transactions into their mempool. Each node will accept whichever valid transaction they see first. This may not be the one that ends up in the block eventually, but the node will correct this once one of the two conflicting transactions has been mined.

So, when a transaciton is being made, before it gets added to the mempool, it gets validated first, right ? and if it's correct, then that's when node adds it to mempool. Correct ?

how does node check if user has the right balance ? it seems like node has to loop through the whole blockchain's UTXO transactions  , isn't that tiresome ? i remember there is something else to quickly check if user has the valid balance.

@NikaKurashvili Computers are ideally suited to that kind of "tedious" task. It's precisely the kind of thing that is nearly trivial for them to do. This is, for example, exactly what any search engine does. And the process of building indexes to make searches efficient is a solved problem.

@NikaKurashvili That's correct, validating nodes will store the entire set of unspent transaction outputs (UTXOs) in order to check that all inputs to a transaction are valid (not just the balance, also that they fulfill all the other conditions such as checking the script or signature required is present).


text:
transaction's limits
I'm new about this market and I don't know if there's some limits about the transactions on the copay wallet. I think to use this wallet for personal and business transactions.
Someone can answer me if I can receive on the wallet several transactions and if there's some limits about btc I can receive?
Tks


text:
Does a blockchain become opaque if it enable's schnorr-signatures, and require trust in the code?
When you sign a transaction with schnorr-signatures, it does not include the pubkey in the transaction data.
1)Does this mean the input addresses become unknown, aka creating a opaque blockchain ?
2) How can one make sure that for example bitcoin still only has 21 million bitcoins ?
3) How does the UTXO set updated and than later on verified by others, seeing only the output address is know.

When you sign a transaction with schnorr-signatures, it does not include the pubkey in the transaction data.

What? Schnorr signature validation still need public keys.

1)Does this mean the input addresses become unknown, aka creating a opaque blockchain ?

No, there are still addresses just like before (or more technically: every input still explicitly refers to a single identifiable previous output which is being spent in its entirety)

2) How can one make sure that for example bitcoin still only has 21 million bitcoins ?

By summing up the value of all UTXOs.

3) How does the UTXO set updated and than later on verified by others, seeing only the output address is know.

Nothing is changed. The UTXO set still contains entries, each of which has a txid, amount, and scriptPubKey. Now you just need a Schnorr signature to spend them.


text:
how to get the sender's address in bitcoinj
I'm trying to modify the simple wallettemplate to get the sender's address in the transaction list. However since TransactionInput.getFromAddress() doesn't exist now and getConnectedOutput().getAddressFromP2PKHScript() is deprecated, I don't know which is the right way to do so.

It's not entirely clear to me why TransactionOutput.getAddressFromP2PKHScript() has been deprecated. It seems to me that perhaps  Andreas Schildbach (who deprecated the method) is trying to discourage people trying to determine a "sender" of a transaction in such a way because of the ambiguity involved (for instance if a transaction has multiple "senders". (See, e.g., here)

Bitcoin transactions don't have a sender's address.
What you're doing is inferring what address previously controlled some or all of the funds involved in the transaction. But:

Previously controlling the funds doesn't mean you found the sender. In case the coins were held by a custodial exchange, the address will be the exchange, and not the sender of the funds. In particular, sending coins back there won't make them reach the right person.
Transactions can be jointly constructed using multiple participants. You can only guess which is which.
The script that previously controlled the funds may not have an associates address at all.

If you want to know what the sender's address of a transaction is, ask the person who sent it (for example if you need a refund address, ask it before showing an address to pay to). If it's not a transaction you're involved in, it's probably none of your business.

public Address getFromAddress(TransactionInput txIn) {
    // get script from connected output
    TransactionOutput txOut = txIn.getConnectedOutput();
    Script txOutScript = txOut.getScriptPubKey();

    // get address from script
    Address fromAddress = txOutScript.getToAddress(MainNetParams.get());

    return fromAddress;
}

thank you! which TransactionInput should I check? if I use tx.getInput(0) I get a NullPointerException. Should I iterate over all the inputs or is it something else I'm missing?

This is the problem with trying to find the sender. A  "sender" isn't a clear idea for a Bitcoin transaction. A transaction's inputs could come from multiple sources. Ultimately, determining which input(s) to consider the "sender" is up to you. As for the NullPointerException, coinbase transactions have no inputs, and I'm guessing that's probably where you're getting the exception. You'll want to skip over the transaction if tx.isCoinBase().


text:
How many addresses are there now with segwit?
Could you help me understand if with segwit activated do we have more available private keys and addresses in the Bitcoin universe?
With Legacy [1...], Compatible [3...] and Bech32 [bc1...] addresses do we have 3x more possibilities ?
Thank you.

P2SH has existed for half a decade, it’s not “compatible”, it’s a re use of existing technology in a new way.

There are 2160 P2PKH addresses.
There are 2160 P2SH addresses
There are 2160 P2WPKH addresses.
There are 2256 P2WSH addresses.
There are 16 defined but unused witness versions which can be encoded by BIP173 (Bech32) addresses, each with data length 2 to 40 bytes. That's 16*256/255*(25640 - 256) =~ 2324.006.

That's 2144363455669619533814323684450670475181580230986810095535626033037852598144837730344835022389248 in total.
The number of private keys has not changed; that's still slightly less than 2256, namely 115792089237316195423570985008687907852837564279074904382605163141518161494336. Only the number of ways to use them increased.


text:
transaction issue
In the absence of someone at home, I noticed two incomprehensible transactions. Why does a large transaction with a n/a address? Or is this some kind of trick of the BItcoin Core client?

Did you do anything abnormal with your wallet recently? Did you restore a backup? Since you don't recognize those transactions, is it possible that your wallet has been compromised?

nothing at all, it simply loaded with OS. because of BTC price, i tried to forget about it for some time

I'm not 100% sure but I think that is when you send yourself bitcoin. I.e. for consolidating utxos

may be, but my balance is 0 now. about 0.8 btc dissapeared


text:
Bitcoind daemon: error connecting to the server?
I am trying to create a new bitcoin address and store it in a shell variable $NEW_ADDRESS.
When I run this command:
$NEW_ADDRESS=$(./bitcoin-cli getnewaddress)

I get the following errors:
error: Could not connect to the server 127.0.0.1:8332
Make sure the bitcoind server is running and that you are connecting to the correct RPC port.
-bash: =: command not found

I have tried everything to fix the connection error, including typing the command:
./bitcoind -rpcport=8332

Or even, changing the bitcoin config:
nano ~/.bitcoin/bitcoin.conf

And typing these lines on the configuration:
rpcconnect=127.0.0.1
rpcport=8332;

But nothing works. Does anyone have an idea on how to troubleshoot and fix this?
Thanks in advance.

try ps aux | grep bitcoind is the process running?

-bash: =: command not found

Leave out the initial dollar symbol when you assign the variable:
NEW_ADDRESS=$(./bitcoin-cli getnewaddress)
Use the dollar symbol when you use the variable:
echo $NEW_ADDRESS


text:
RPC giving error -13
Bitcoin rpc calls giving error
-13: Error: Please enter the wallet passphrase with walletpassphrase first.

Your wallet is locked with a passphrase, first you need to unlock it before executing commands related to private keys using walletpassphrase:
# Unlock the wallet for 60 seconds
$ bitcoin-cli walletpassphrase "my pass phrase" 60

# Some transaction commands ...

# Lock the wallet again (before 60 seconds)
$ bitcoin-cli walletlock

i am running the bitcoind-cli in regtest also i have not added any passphrase

The wallet is protected with a password. You can always delete your regtest files and start over

when i have  first time started the reg test at that time i have not created any wallet passphrase , if there is already wallet passphrase created then how can i see that , Is there is any conf file that store the wallet passphrase ?


text:
Web wallet making direct RPC calls to bitcoin node
Is it good idea to make direct RPC call's to node computer to generate web wallet addresses
here is what i am trying to implement
i want to create new web wallet based on bitcoin and want to allow the users to create their own wallet , and also send and receive the tokens or cryptocurrency

If you want to do it from front-end (web browser) it's not a good idea because you will expose an access to your bitcoin node so anyone able do anything with you bitcoin node, if you want to do it on the server so it is normal practice.
Just don't expose your RPC node access, allow connections only from localhost.

yes the frontend will be in angular 6 and backend will in django. Django will make further RPC calls to the node computer.

Further one question all the secured web wallet make RPC calls to the node ?[server to server calls ]

There is a lot of implementation opposite of RPC, some of them use IPC others communicate direct to the node.


text:
In which file node rpc details stored in Insight-api
Bitpay insight api  https://github.com/bitpay/insight-api allows blockchain epxlore functionality
I cant find the files in which insight-api store the rpc details ?

What do you mean 'rpc details'?

rpc user name and password for getting the blockchain data.  as this insight-api listing the blockchain data ,i think it must be connected to some  node.

Typically nodes do not connect via RPC in order to sync blocks


text:
how to set the transactions fee using the RPC call?
I am creating the web wallet for the bitcoin , I want to allow web wallet users to set the transactions fee .
Is their is any rpc call available for setting the transactions fee (for setting transactions priority) ?

When creating a raw transaction: Inputs - Outputs = Fee. If creating a raw transaction you'll need to calculate this yourself.
https://bitcoin.org/en/developer-examples#simple-spending
The link above will provide examples. You use their built in calculation or build your own raw transaction and set whatever fee you like by using Inputs - Outputs. There is no "rpc call" to set it that i can find or have heard of.
You can set variables for WALLETS in the bitcoincore config, but as you stated, you're working on managing multiple wallets for multiple users. Not sure if having bitcoincore manage every one of your wallets for a large number of users is viable or even possible. If i'm wrong, check this out:
paytxfee vs maxtxfee which one overrides the other
Either way that's not the answer as it's not an "rpc call".

The RPC you're looking for is settxfee, which sets the fee per kilo(v)byte.
For example bitcoin-cli settxfee 0.00027100 is making bitcoind use a feerate of 27.1 sat/vbyte for all future transactions.

This is true and relevant if Bitcoin Core is used a the wallet.
However, in a wallet implementation, where the wallet puts together transactions (collects inputs, selects a subset, performs fee estimation, adds signatures) it is the wallet who deals with these, and the node is used only for broadcasting the transaction.

@AdamB Yes, the fee rate choice is something to be conveyed to the wallet software you're using. If that's not the Bitcoin Core wallet, you'll need to use the mechanisms that exist for that software instead. The question referred to RPC calls, however, so I assumed the asker was using Bitcoin Core.

Yes there is ‘estimatesmartfee’ which computes fee with high confirmation probability within n blocks.

https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list
I cant see estimatesmartfee rpc call . Please let me know the parameter that is required for this rpc call.

https://bitcoincore.org/en/doc/0.16.0/rpc/util/estimatesmartfee/

estimatesmartfee   , i cant see the option to pass the argument for the account , i want to set the fee specific to account name .
As i can understand it will specify the fee for complete wallet. In my case  main wallet has different wallets with different account name or label. With above methods all the accounts have the same transactions fee

@James C.: OP is asking about setting the fee, not estimating it.

I misunderstood. Apologies.

James can you please let me know if there is any RPC method for setting the transaction priority. On the blockchain.com while sending the bitcoin user can set the Transaction fee. Can you please let me know which RPC call they are using for setting the transactions priority


text:
how does node create UTXO from blockchain for the first time?
Let's say I am a new node.
I try to synch with the full node to grab the whole blockchain. Now, I synced with it .It's time for my node to create UTXO database ..
How does it do this exactly so that it knows which one to put in UTXO database ? since it will need to know which one is unspent. By looking at the blockchain, it can't quickly figure out which one is unspent for the following Reason: 1st height block contains output which has 5btc sent to me. I only spend this in the 400,000th block. This kind of thing happens for every other output. So how does bitcoin build UTXO in an effective way ?
It would also be great if there could be any code from bitcoind or something so i can take a look. Couldn't find it myself.

The UTXO set is updated every time a block is connected to the chain. So if you imagine during initial sync, you download block #1 and verify it, then add one UTXO to the database (the coinbase output). Block #2 gets downloaded and verified, and you add one more UTXO to the set and so on. Eventually you download block #1000 which contains a transaction that spends the coinbase output from block #1. If everything is valid, you delete that block #1 coinbase output from the UTXO set and replace it with whatever new coins are created by the transaction in block #1000.
So your assumption that "Now, I synced with it. It's time for my node to create UTXO database" is incorrect - the UTXO database is always under constant maintenance from the moment you launch bitcoind.
To start digging through the code, note this call to UpdateCoins() in the function ConnectBlock(). This will eventually call AddCoins() and you can see the UTXO are actually added to a cache first (which is eventually flushed to disk). But this is the mechanism you are looking for.
You can see where coins are removed from the UTXO cache in SpendCoin()

so let's say utxo database is key value and keys are txid+vout. node checks txid+vout in inputs and if it's present in utxo , then it removes it from utxo. something like this ?

yes, I added some links to code in the answer

Before I check the code ,quick question. how does node know if an input is coinbase transaction ?

coinbase tx can be identified because their inputs are null (they "spend" from a txid of 32 0x00 bytes) You can the function isCoinbase() in transaction.h

Thanks .  do nodes also try to download utxo sets from other nodes? because if i am a new node, syncing with other nodes might take lots of time(downloading blockchain, creating utxo) . does bitcoin do something like ethereum does ? downloading state trie and blockchain in parallel ?

That is not currently possible because there would be no way to verify the data is accurate. There have been several proposals to enable this however: search for "UTXO commitments" on this site.

Also check out: https://dci.mit.edu/utreexo


text:
How to calculate the transaction size?
Is it possible to calculate the transaction size from the transaction id ?

I think this should answer to your question more than exhaustively. If yes this can be marked as duplicate, I suppose.

No. That's not possible.
A transaction id is calculated from the raw transaction. More specifically the raw transaction is hashed twice with sha256: sha256(sha256(rawtransaction)).
That means, that the id is always 256 bits long (64 characters).
Because sha256 and hashing in general is a one-way-operation, it's not possible to calculate the size of the rawtransaction just from the transaction id.
if you need more information about a transaction, you have to fetch that from a client. In bitcoin core you can use gettransaction or getrawtransaction. (getrawtransaction only works if the transaction belongs to one of your addresses or you have txindex enabled in your wallet.)

TXID is dsha256 +endian swap of the over-the-wire transaction serialisation.

That is part of the p2p protocol, not implementation, as this is how txids / prevouts are referenced in overthewire tx serialisations.


text:
Why estimatesmart fee returning the same fee for diffeent blocks number?
I am trying to calculate the fee per kb using the estimatesmartfee.
I had called estimatesmart fee with  different type of blocks number .The fee remaing the same.
estimatesmartfee(2)=estimatesmartfee(6)=estimatesmartfee(24)
above statement seems to be correct . Please let me know if there is some another changes need to be done using the estimatesmartfee

The estimatesmartfee fee estimation algorithm maintains local historical records of two things:

Transaction fees (sat/B) of confirmed transactions
Target Intervals: Blocks between mempool acceptance and confirmation

Based on these records, the algorithm will be able to provide an estimation of the minimum fees required to obtain confirmation within your specified block interval target n.
Specifically, when you query estimatesmartfee(n), you are asking for a 95% historic probability that your transaction will be mined in n blocks.
There are two possibilities for why estimatesmartfee(n) will return equal fees for different targets.

It returns -1: The method doesn't have enough historical mempool records to perform the estimation.
For the mempool records on your local server, the fee rates for 95% confirmation probability within your indicated target values n fall within the same fee bucket range, resulting in the same sat/b values returned.

You may want to run the server a little longer and see if these values change.

What values is estimatesmartfee returning for estimatesmartfee(2)=estimatesmartfee(6)=estimatesmartfee(24)?


text:
Is it required to broadcast the addresses generated locally to the bitcoin network?
Like the transactions  are broadcasted to the bitcoin network , is it required that locally generated addresses also need to be boradcasted to the bitcoin network ?

No, you can generate trillions of addresses (private keys) and the rest of the network don't need to know about them until you make transactions to each of them.

Is this means that Suppose i have generated the address  locally and now i want my friend to send me coins then is that means he can send me directly  ? or my locally generated address will be firstly added on blockchain ?

@PankajKumar You should send your address to your friend, e.g. via message/SMS

yes that need to be send to my friend firstly only then my friend able to know that whats my address, thanks i found the answer


text:
Strange values in Bitcon Electrum wallet file (change and receiving)
I am performing a forensics analysis of a Bitcoin Electrum wallet. When I open the file manually, there are values like this (changed it a bit):

"accounts": {
    "0": {
        "change": [
            "039de61d6f91d6e419641ef61d5df1f65d1fddddfd6fd1e84fe6fd1f1d6dfb5958",
            "02f2ffe6f8d6df5df6e84f684fdf5416d1f6e8ef4964ffd3f3dfdfefe46f1d1f56",
            "037bf6d541df651df3513df1d3f1d35fe6f4e6f4d5fd65fe65f1d3f1d3f1dea996",
            "0266e5f1d651df6d1f6df1dfff6df51d65f1d65f1d6f46ef4ef65f1eff65e1fd3f",
            "02651e65e1e1d1d6e1e5e1e6e6e6e6e65e1e1d31fd3f1d35df13d1f3d5fe216e71",
            "036ef6d1f351d3f131df3df13d51f1d351fd35135151111131df35d1f3df13dcc2"
        ],
        "receiving": [
            "03f6d41f6d51d31df3fe13f1d3521fd35fe5131ff1f11f133fd31fd35d1fd3f639",
            "026e61fd6df1fd6fd6f16d1fdc6c1d6f1d6f1e61f8d4d6c1d65f6df1df1d3f5e14",
            "03ef1dsdgsdgsg6f1d6d1c6d51fd651fed1c63d13fd13f1d32f1d3f31db5e8286a",

...

I thought that these should be just addresses, but obviously they are not. It gets even stranger when I import the file into Electrum - it then automatically changes these values to addresses (in the file too). I don't think, that it's something like a private key - it's 66 chars long. Even if - when imported, Electrum still asks me for it.
What does this all mean and how do I get information about transactions/addresses/amounts?

look in the keystore section for private key data. if you can extract that then you can restore your wallet with it and electrum will recreate the rest.

The fields you are seeing are raw ECDSA public keys.


text:
Explanation of Blockchain Payment systems
Trying as much as possible to understand what Blockchain technology is (As i am trying to see if i can be a Blockhain developer) and I just worked on a money transfer system myself and i hear everyone talking about blockchain being the next to important thing in order to develop a money payment system.
following what i read on the internet , a system using blockchain technology should have the following capabilities,
1.) After making the Payments should generate the block and generate the block hashes and save them to be used as a transaction Log Later on, in order to trace the history of the payments from the beginning till its present state... 2.) Peer-to-peer Allowing users to make payments and view track of the transactions etc
Now i want to understand in its short meaning, its this what blockchain is all about?

This is far too broad, and is missing several important points. I would strongly suggest reading a comprehensive guide such as Mastering Bitcoin, and coming back with specific questions.

Agreed. Mastering Bitcoin is the goto introductory work that explains both in overview and in detail what Bitcoin and the Blockchain are for, and what problem it solves.

A block chain:
Block - a chunk of data
Chain - a sequence of links
So you need some data, and you need it to be inviolably linked to another block of data (repeatedly) forming a chain. In essence you take your first block of data, hash it, and append the first hash to the first data. For your second block of data, you include the first hash in the second block of data, the ph hash the whole lot to get your second hash. The second hash forms part of the data in the 3rd block. In pseudocode
Hash1=calc_hash(Data1)
Block1=Data1+Hash1
Hash2=calc_hash(Hash1+Data2)
Block2=Data2+Hash2
Hash3=calc_hash(Hash2+Data3)
Block3=Data3+Hash3

This is how the chain link between blocks is established - the hash from block N is involved in calculating the hash for block N+1. If you alter the data for block N, the hash will fail. If you calculate a new hash and try to pass it off as legit, the hash for block N+1 will fail.. and so on
It’s not new.. for many years longer than bitcoin has existed credit card terminals in certain countries have been communicating using a protocol that hashes each transaction and uses part of that hash in hashing the next transaction. It provides tamper deterrence/checking and also allows some nifty tricks such as telling the bank in a subsequent transaction whether the previous transaction was voided or not. Bitcoin might well pack many transactions into a block but it doesn’t have to- the credit cards terminals I mentioned for example, have a single transaction per hashed block


text:
After Setting up my Bitcoin core Server, I need to create wallets for each of my client on a website may be thousands
After Setting up my Bitcoin core Server, I need to create wallets for each of my client on a website may be thousands.
How can i generate wallets on per user basis that if bitcoin core does not allow me.

I need to create wallets for each of my client on a website may be thousands

There are several ways to generate addresses in bulk. Using Bitcoin Core exclusively you can create individual wallets with the createwallet command in the RPC and then create new address with getnewaddress although you will have to do this programmatically as there is no built-in functionality for the creation of X number of addresses at a time.
A faster alternative outside of Bitcoin Core would be to use a vanity address generator such as VanityGen. The initial intention of VanityGen was to allow for the creation of unique/custom addresses with specified prefixed characters otherwise known as "vanity" addresses. Luckily this tool has an array of command-line parameters useful for bulk addresses generation too. VanityGen utilizes your graphics card (OpenCL-compatible) making it significantly more powerful than the standard CPU generation found in the Bitcoin Core client. Similarly, it works both online and offline.
Using the 64-bit Windows binaries provided on the project's GitHub, I can use the following command-line options:
vanitygen64 -o key_pairs.txt -v -k 1

-o Specifies file to write key pair to (Pattern, Address, PrivateKey)
-v Makes output verbose (Provides Pattern, PublicKey, PrivateKey, Address in stdout)
-k Continues search after finding a match (run infinitely until exited)
1 This is what the vanity generator will look for as a prefix.
All of the generated addresses and their private keys will be listed in the output file (key_pairs.txt in the example). You can parse this file and assign each of your "clients" a private and public key pair as well as the address that goes along with it.


text:
Drastic decrease in peers
Been running a standalone node on the same hardware for some years now. I run this node simply as a supportive node, unlocked bandwidth to facilitate people bootstrapping the blockchain. No settings have changed recently. I noticed in the last week or so that peer count has dropped drastically, from 200+ to less than 40. Peer count used to fluctuate 190-250, now it fluctuates 39-55ish.

A reboot of the router and modem did not change peer count
significantly.
I deleted and re-assigned the port-forwarding rule to rule out some
firewall malfunction.
Verified the port is open using a scanner from the internet
Reloaded UFW on the node just to be sure
using bitcoin-cli netinfo 4 I'm able to verify there are    30+
incoming connections spread over onion and IPv4
Speedtest on my internet connection is otherwise normal
Server disk/memory/CPU usage all well less than 50%

My current bitcoin.conf includes:
maxconnections=256
maxuploadtarget=1000000
server=1
daemon=1
bind=0.0.0.0
onlynet=ipv4
discover=1

My questions:

has anyone else noticed a decrease in connections?
Is it possible my ISP is somehow throttling bitcoind p2p connections?

I understand that it doesn't really matter how many nodes I'm connected to, but when there's a sudden, drastic change not due to some configuration change on my part, I start to wonder what's going on and if there is some attack or issue with the p2p network.

I have not noticed a decrease in peers on my node. Is it possible that your IP address has recently changed and it hasn't fully propagated through the network yet?

My IP address is essentially static and has been stable for a period of many weeks


text:
Seed recovery from paper wallet
My friend has found a file that seems to be a Bitcoin paper wallet backup, but it has quite strange seed encoding that I have never met before. It has:

A field named "Key" - a short string (11 chars) with letters and digits
90 numbers each 6 digits

Does anyone know how to decode such type of paper wallet?

Is your friend sure this is Bitcoin related? What makes them think that?

I'm not sure. This file is named Bitcoin, and inside, it has instructions to print it on paper to backup

Because the exact instructions etc might help identify the file, it might help if you edited the question to include a modified copy of the whole file that has the 11-character key replaced by XXXXXXXXXXX and each of the 90 6-digit numbers replaced by NNNNNN (and same for any other numbers/strings that might need to be confidential)


text:
My full node seems to be rejecting tor connections
I'm running my full node with bitcoin core v0.18.1 with a mostly default configuration on debian 9.11. Port 8333 is forwarded through my router and I have 20+ node connections, so can safely assume others are able to connect, at least through ipv4. A friend was testing his tor node however, and received the following error when attempting to connect to my bitcoind's tor hidden service address: Socks5() connect to XXXXXX.onion:8333 failed: connection refused
When I run bitcoin-cli getpeerinfo I can see *.onion addresses in the list, so I presume others are able to connect through tor, is that correct? I'm using UFW and have 8333 open from all addresses, although tor connections are through localhost so UFW rules shouldn't matter. Why does my node reject the connection to my friend's node?
Here's my bitcoin.conf:
bind=0.0.0.0
onlynet=ipv4
txindex=1
listen=1
maxconnections=256
dbcache=400
upnp=0
discover=1

Turns out my node had auto-banned localhost (127.0.0.1) at some point. As a result bitcoind was rejecting all incoming connections from the tor service, including my friend's attempts. I removed the ban and he is able to connect.

Do you mind explaining how you removed the ban?

I use Bitcoin Node Manager as a front-end for my bitcoind instance. It has a section to remove a ban on a specific IP. Note that I believe the auto-bans generated by bitcoind expire in 24 hours, so you could just wait a day. It's likely also possible to remove a ban on the command line with bitcoin-cli, although I'm not sure exactly how.


text:
How can I find real man for bitcoin mining investment?
can anyone help me for find a real people? Where I can invest for mining, because i lost lot of money before. Someone scamming with me.
Thanks

Mining bitcoin requires specialized hardware, and a certain level of technical expertise. Anyone advertising that you can 'invest in mining' with them is almost certainly running a scam. Unless you are purchasing mining hardware (an ASIC machine) to set up and run yourself, you are likely getting scammed, or at least being taken advantage of.

See In the ASIC-age, is it worth starting mining Bitcoin at home? -- Getting involved in Bitcoin mining is not suitable for anybody who is new to Bitcoin. You will almost certainly lose even more money.

The only real "safe" way to invest in mining is to simply start mining yourself. There are many online resources for teaching you how to do this. Depending on the price of Bitcoin, your local electricity, network difficulty, and the price of your equipment your profitability will vary greatly. In most cases it may make sense to just buy and hold the coin and perhaps play around with trading in general.


text:
Struggling to successfully broadcast a p2pkh transaction
I've been experimenting with sending bitcoin transactions with python for the past week. I successfully was able to send p2wpkh->ALL address types, p2sh-p2wpkh->ALL address types.
What I am struggling with is sending a legacy p2pkh transaction. I keep getting:
SIGNATURE MUST BE ZERO FOR FAILED CHECK(MULTI)SIG OPERATION
when I try to broadcast the signed transaction using https://testnet.smartbit.com.au/txs/pushtx
It seems to me like it is a signature error. But I can't understand why I am able to generate good signatures for other payment types but then bad signatures for p2pkh.
My rawtx:

01000000 01 4f8fe5092e16ad3da3327c36a6c5209c9aede34fc68615cfdf3049945e91ca61 00000000 00 ffffffff 02 4c4f000000000000 1976a9143f7ff5e4d9b36cbce77199043d5cf51b5fb4e8d188ac 546f4b0000000000 1976a9143f7ff5e4d9b36cbce77199043d5cf51b5fb4e8d188ac 00000000

My signed TX:

01000000014f8fe5092e16ad3da3327c36a6c5209c9aede34fc68615cfdf3049945e91ca61000000006a47304402205881bb01ff20100233d6c1284eb6fe1857fb25a8cee52f5fe48ef8bbf61e42fe02201b00187031f299283b60b214d801c5ca0db8342a8e68c8020caf96e9a064b471012102a7b51771f972f4d2de85129886415af3e13efe943c12f149ab7c43c318f45ae9ffffffff024c4f0000000000001976a9143f7ff5e4d9b36cbce77199043d5cf51b5fb4e8d188ac546f4b00000000001976a9143f7ff5e4d9b36cbce77199043d5cf51b5fb4e8d188ac00000000

Signed tx parsed with my python parser:
Segwit: False
txn version: 1
Flag: 00

------------------------------------------------------------
Inputs: 1
------------------------------------------------------------

(1)
Previous txn hash: 61ca915e944930dfcf1586c64fe3ed9a9c20c5a6367c32a33dad162e09e58f4f
Index: 0
sigScript: 47304402205881bb01ff20100233d6c1284eb6fe1857fb25a8cee52f5fe48ef8bbf61e42fe02201b00187031f299283b60b214d801c5ca0db8342a8e68c8020caf96e9a064b471012102a7b51771f972f4d2de85129886415af3e13efe943c12f149ab7c43c318f45ae9
Sequence: ffffffff

------------------------------------------------------------
Outputs: 2
------------------------------------------------------------

(1)
Value (satoshis): 20300
pubKeyScript: 76a9143f7ff5e4d9b36cbce77199043d5cf51b5fb4e8d188ac

(2)
Value (satoshis): 4943700
pubKeyScript: 76a9143f7ff5e4d9b36cbce77199043d5cf51b5fb4e8d188ac

--------------------

Locktime: 0

Can I use compressed public keys in normal p2pkh transactions or does it have to be normal uncompressed?
In my script I build the preImage the same way as my other segwit inputs/outputs but obviously I dont use flag, marker witness fields. I also followed another post on here attempting to only sign a single input and I got other errors different from the one at the top of this post.
How does the segwit signing process differ from legacy?

I wrote something similar in Python that might help you. Check https://github.com/mcdallas/cryptotools/blob/master/btctools/transaction.py#L472 lines 472 - 532 for the difference in the preimage between legacy and segwit.

I've already got it figured out but I looked at your library and it looks nice.

Nevermind.
I combined the two answers from these posts and managed to get something working:
Redeeming a raw transaction step by step example required
https://bitcoin.stackexchange.com/a/41226/89247
Yes. You can use compressed public keys with p2pkh. There are no restrictions.


text:
what things may I need to start withdrawal of bitcoins
I'm new on bitcoins business the problem now is to withdraw my bitcoins to my account or exchange it to normal cash.

Why exactly is this a problem?  There are MANY services that will trade cash for bitcoin. A simple web-search will find them.  What is the question?

Transfer them to coinbase.com or gemini.com then sell them. Then add your bank account and withdraw the money you just sold your bitcoin's for.

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


text:
Should I use bitpay?
Looking to store .145 of bitcoin in a strong wallet. Should I use Bitpay for this? If not, please recommend better wallets. No hardware wallets please, I am trying to save money.

related: What is a good resource to help newbies choose their first wallet/s?

Electrum (https://electrum.org) is a good choice if you wish to store your bitcoin locally on your PC.   Supports things like hardware wallets, multiple wallets, seed (longish string of words) to recover your wallet if it's lost, and you can later on export your keys and import them into another wallet if you prefer.

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


text:
Can I use Electrum on my everyday computer?
Or do I have to use a computer that has never used the internet?

There's nothing stopping you from using Electrum on an online computer. If you have a lot of coins and want to have better security, you should use an air gapped setup where the offline computer has the private keys and has never been online nor will ever be online. Or you could use a hardware wallet. But using Electrum on an online computer and using a strong password (on your computer and on your Electrum wallet) is also fine.


text:
Segwit txin. Witness data association
I am trying to learn more about the bitcoin protocol and I am writing some python software to make a light wallet. I have advanced quite far and I have come across something that I dont really understand while reading about segregated witness protocol changes in terms of transactions.
https://bitcoincore.org/en/segwit_wallet_dev/
If you go here and read the part with a heading "Transaction Serialization" the text reads like so:

If a txin is not associated with any witness data, its corresponding witness field is an exact 0x00, indicating that the number of witness stack items is zero.

How do I know if an input I am using in my script is associated with witness data? I have tried using public API's to look at the outputs I am using and I cant understand what it means. I see witness fields associated with the inputs of the transaction that produced the outputs I am trying to include in my transaction but not the other way around..

Are you trying to create a transaction, or trying to parse an existing one?

Trying to create a transaction. I would use the addresses to determine it but I know that it is impossible to tell a P2SH from a P2SH-P2WPKH

You need to know what you're signing. Obviously you can't create a signature without the private key; equally you need to know whether it's a multisig or P2SH or P2WPKH or whatever script you're signing. The address is never enough.

Understood. So if I have a bech32 or a p2sh-p2wpkh the input I possess will always be classed as being associated with witness data? But with a legacy address it will be never associated?

Spending a segwit output always requires a witness. Spending a non-segwit output never requires a witness. But I don't see how this information is helpful; you still need to know exactly how to construct the scriptSig and witness anyway, which depends on the type of script you're spending. It just so happens that all segwit scripts need a non-empty witness while others don't.

I'm just trying to get my head around dynamically changing the serialization format based on if I want to spend an output from a segwit or none segwit address.

The serialization doesn't depend on the output; only the data being serialized does. The zero byte just indicates "empty witness", in every situation (either spending a segwit or non-segwit output). An non-empty witness can not occur in a valid transaction that spends a non-segwit output, but your serializer shouldn't care about that.

One more thing. I should probably open another question but I think it would be a repeat of https://bitcoin.stackexchange.com/questions/61290/what-is-ment-by-the-value-of-the-output-spent-by-this-input-in-bip-143. If I have multiple inputs what would the amount be for the hash preImage? I'm thinking the amount of the last input but I am not sure. It isn't very clear.

The amount being spent by the input you're signing for.

But in the examples in https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki he has multiple inputs but he is only signing once. This is so confusing.

In the signature(s) for input 1, you sign the amount that input 1 is spending. In the signature(s) for input 2, you sign the amount that input 2 is spending, etc.

Did not realize you have to sign each input separately. That is frustrating.

It's really the only way. Each input can spend unrelated outputs (each from a different address, with different keys - all those keys need to sign off to authorize the transaction). It's also why there is a scriptSig/witness per input, and not one globally for the whole transaction. There is ongoing research on how to integrate multisignature schemes into Bitcoin, which would permit a single signature that proves all keys signed off, but that won't be available anytime soon.

How do I know if an input I am using in my script is associated with witness data? I have tried using public API's to look at the outputs I am using and I cant understand what it means. I see witness fields associated with the inputs of the transaction that produced the outputs I am trying to include in my transaction but not the other way around.

I believe your confusion is due to this line

If a txin is not associated with any witness data, its corresponding witness field is an exact 0x00, indicating that the number of witness stack items is zero.

not applying to the serialization format, but to the contents.
A witness is always serialized as:

A variable-length integer indicating the number of witness stack items n.
For each of the n stack items:

A variable-length integer indicating the size of the stack element b
A b-byte array with the contents of that stack element.

A corollary is that an empty witness is always serialized as just a 0x00 byte (indicating that there are zero stack items).
So your serialization and parsing code does not need to know whether a particular txin has associated witness data. It just serializes/parses the witness, which may be empty.
It so happens that the validity rules require that the witness for a non-segwit spend always has to be empty, and as a result, the serialization of such a witness will always be just 0x00.


text:
Does Bitcoin Core v0.17.0 run on native wayland?
I'm trying to run bitcoin core v0.17.0 on Wayland on Fedora 29. When I run bitcoin-qt I receive

Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.

Running with QT_WPA_PLATFORM=wayland yields

QSocketNotifier: Can only be used with threads started with QThread

Is there a configuration change that will allow bitcoin core v0.17.0 to run on native wayland? Or what is the best way to provide a bug report to the core devs regarding wayland issues?


text:
Can I safely delete database.bak from wallet folder?
In order to save space.
I cleaned it up and now my bitcind in freezing, but this might not be the cause.

The block files are 220GB. Why are you deleting random, small files that the software relies on?

It is not a block file. It is particular wallet file

I understand, but it’s meaninglessly small compared with the total storage used.

I store around 5000 wallets (and aim for a 1000000), each wallet can weight up to 6,5mB, so it is a significant space

Why on earth are you doing that?

I develop a project with users wallet management

That doesn’t require you to store a wallet for each user. Nobody else is doing this, so you’ve run into an edge case as a result- no service stores > 32GB of individual wallets.

'Nobody else is doing this' newer was an argument :)
I can't manage wallet if i don't own it (if i don't have transactions history): I wouldn't even be able to get wallet balance


text:
Can I send almost 1MB transaction?
Block size is still limited to 1MB. As I understood, transaction size is no longer limited. So can I be sure that my transaction with 29000 outputs and reliable fee will be included into block?
Or what is the max transaction size?

Yes, but the question and both answers are not relevant now

Related: Block 364292 is basically one massive transaction: https://blockstream.info/block/000000000000000003dd2fdbb484d6d9c349d644d8bbb3cbfa5e67f639a465fe

Can I send almost 1MB transaction?

To be able to send a transaction that a miner will accept, that transaction has to be a standard transaction. As defined in policy.h
/** The maximum weight for transactions we're willing to relay/mine */
static const unsigned int MAX_STANDARD_TX_WEIGHT = 400000;

For non-Segwit transactions, the limit is 400,000 KB / 4 = 100,000 B = 100 kB.
Therefore, if you have a Pre-Segwit transaction larger than 100 kB but smaller than the block s̶i̶z̶e weight limit, you should contact a miner, and they'll be able to add your transaction to their block manually, if it's profitable for them.

So 100kB limit still persists, I was confused by the comment to https://bitcoin.stackexchange.com/a/35882/92719 . Thanks a lot

You're welcome. If you have any other questions, I'm happy to help.


text:
First time user. How can I recover my BTC?
I've done hours and hours of research trying to unstick my coins with no luck. I bought them off coinbase and transferred them to this stupid google app called sparecoins, from there I transferred to blockchain and then spent them from there. I had no idea really what I was doing. I didn't realize they had to be confirmed. So my money made it to sparecoins app confirmed but after that the next 2 stops it never made it. They sit stuck. Nobody stole it or used it, it's just stuck. The sparecoins app (which I should have never used) has a back up wallet button which makes a file opening the file with notepad it has this at the top "Encrypted Privated Keys (AES) Use a SHA256 digest of your password as the encryption key" and 13 lines of jumbled up letters. I've tried and tried and can't figure out how to recover these funds. Can anyone help?

Do you have transaction IDs?  It sounds like your transaction from Sparecoins to Blockchain is simply unconfirmed.   There is currently a backlog of about 150,000 unconfirmed transactions on the network.

Encrypt your addon password here https://myeasywww.appspot.com/utility/free/online/Crypt_Decrypt-MD5-AES-HMAC-SHA-DES-RABBIT/en?command=UTILITY&ID=2
Copy the result from sha256result.
On this site https://www.browserling.com/tools/aes-decrypt
enter the encrypted key from the "download" file in the top box, your encrypted password in the bottom
The result should be your private key, you can create a new wallet https://blockchain.info/wallet/#/signup and import via settings, addresses, import bitcoin address


text:
Would you need to access your cold wallet to generate a taproot xpub?
If you would like to generate a taproot wallet with your deep cold wallet seed, would you need to access the wallet to generate it?
Say if the seed/master pubkey is already used for native or nested segwit.

You're using the word wallet twice here, presumably in a different meaning. Clearly if you're generating a new wallet, you don't need any existing wallet already.

I assume you mean that you have something like a hardware wallet where you have a seed and different kinds of addresses generated using xpubs derived from that seed.
Assuming that the xpub will be generated using the derivation path standard defined in BIP 86, then yes, you will need your cold wallet. That standard derivation path uses hardened steps which require access to private keys in order to derive.


text:
Would signature aggregation reduce the largest feasible blocksize
If a Schnorr signature aggregation scheme were to be integrated into Bitcoin. Would the reduction in witness data versus non witness data (need less bytes for a signature therefore witness data usage would go down per tx) create a lower upper limit on potential blocksize (believe the realistic upper limit is 2.5 MB rn)?

SegWit blocks aren't limited in bytes anymore but rather in weight. The maximum weight for a block is 4M. The weight of non-witness data is 4x its number of bytes.
So, yes, decreasing the amount of signature-data frees up some weight which can then be filled by more transactions. Yet those new transactions also contain some non-witness data which is more costly. An average full block will still be 4M in weight, but reduced in size (bytes) while containing more transactions. Both are good news.


text:
how does merkle root building work for empty array?
It's known that even if no transactions get created, bitcoin still creates a block with empty array of transactions.
In this way, I am curious what the merkle root would be. How does bitcoin figure out merkle root for empty array ? if there're even 1 transaction in it, I understand completely what it does, but what about empty array ?

This cannot happen. Every block contains at least a "coinbase" transaction that distributes the subsidy and fees to the block's miners.
Blocks without coinbase are invalid, even if the subsidy were 0.


text:
how does node validate scriptSig
Let's say I sent some BTC to Bob, so I created a transaction (forget about scriptPubKey) since let's say I was able to prove it by executing scriptPubKey. so After I sent BTC to BOB, new transaction's input looks like this:
in: [
  {
     "prev_out": {
        "hash": txId,
        "n": 0
     },
     scriptSig:"3045....e5f5"
  }
],

Now, this scriptSig exists because when other nodes come and see this, they should be able to validate it. Now, all we have here is the signature , public key (mine), txId(output transaction that I used).
How can another Node which got this transaction validate it ?
You might say: he will see signature + public key of yours. so what will it do to validate it ? if you say that it will try to decrypt signature with public key, that's not enough. Because what I could do is encrypt blablabla string my private key and I'd put that signature there.
So I guess, my question relates to: how Node will prove I proved that I had BTC with scriptSig + txId ?

Related: https://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx

hi Andrew, it's kind of a huge explanation and was looking for a easy one. my question simply relates to only one thing: when node looks at scriptSig of the input, how does it know that it's legit ?

What you are asking about is the message covered by the signature. In Bitcoin, this message is defined by the consensus rules and is a modification of the transaction the signature is contained in.
The exact form of this message for non-segwit transactions is explained in How to redeem a basic Tx?

message signed by the signature or private key ?

The message covered by the signature. I.e. what the signature commits to.