text:
Local broadcast cannot be found in mempool
After sending a raw transaction (SendRawTransaction (raw_tx, 100000)) and after local broadcasting, the transaction does not show up on platforms such as mempool.space. What might be the reason?

What does your debug.log say after you submit the transaction? Is it perhaps a conflict?

There is no error message, but the txid cannot be found in the debug.rog. However, the client. sendRawTransaction returned the txid. Is it possible that my transaction was not broadcasted? How can I make mempool or other mining pools receive my transaction

Is your transaction non-standard? Anything special about it?

This is a full RBF transaction with a rate exceeding 10000. Is there any platform that supports transactions with a rate exceeding 10000? Mempool.space will prompt "code": -25, "message": "Fee excesses maximum configured by user (e.g. - maxtxfee, maxfee)"

Assuming you mean 10,000 sat/vB, you may be overpaying by a factor of 3,000× currently. That’s why the 1,000 sat/vB warning is implemented in some wallet software. Are you reprioritizing a parent transaction so that you actually want to pay that much?

The second argument in the sendrawtransaction RPC is maxfeerate specified expressed in the unit [BTC/kvB].
100,000 BTC/kvB = 100 BTC/vB = 10,000,000,000 sat/vB

The value of 100,000 BTC/kvB that you provided is vastly in excess of sane feerates, so it looks like your node may have not broadcast the transaction to prevent overspending. As the documentation states, if you are willing to accept any feerate, you can set the second parameter to 0. I would however encourage you to carefully validate that your transaction is sending the remaining amount from the inputs to change outputs, which is a commonly overlooked issue with using raw transactions, as the combination of accepting any feerate and forgetting to specify a change output may lead to the majority of your funds being dropped to the transaction fees.


text:
Is there a Bitcoin Core RPC that creates a block including merkle root and coinbase based on my address?
Trying to get some commands that can construct the block body for me, and then output that along with the Merkle root, based on an input address.
It's fine if they are done as two separate commands, like "savebody" and "getmerkle" or something, I've just been looking through the API and I'm not sure what will do these functions.

This question is similar to: How to hash data from 'getblocktemplate' request. If you believe it’s different, please edit the question, make it clear how it’s different and/or how the answers on that question are not helpful for your problem.

I believe the "normal" processes are described at
https://en.bitcoin.it/wiki/Getblocktemplate
which I think too long to quote here in full.

In case you are not looking for the getblocktemplate RPC or the generatetoaddress RPC, could you perhaps elaborate what you are trying to achieve?

@murch im not sure how else to make it more understandable. Just a function that blocks together transactions. and another one that outputs a merkle root

In short, no such RPCs exist, though there are a few related ones.
There is the "production" mining interface getblocktemplate, which is used by mining software (pools, solo, ...). It gathers transactions from the mempool to be included in a block, and gives information about it. It does not compute a coinbase transaction (to pay out the mining rewards), and thus also cannot determine the Merkle root (as that depends on the coinbase).
For testing purposes, there are "all-at-onces" RPCs like generatetoaddress, which gather transactions, construct a coinbase transaction to pay out the reward, compute the Merkle root of the resulting transactions, and then grind the block nonce in order to construct a fully valid block.
It sounds like you're looking for something in between, which is everything that generatetoaddress does, but without the grinding. This doesn't exist, and it doesn't seem very useful to me. For production use, you want the coinbase to be constructed on the mining side (because modern ASICs are so fast that they need thousands of new coinbases per second, which just wouldn't be feasible to do inside Bitcoin Core), and for testing purposes it generally suffices to either do everything at once, or do something so custom that the entire process is done within test code.

source: Stack Exchange

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

sort: votes


text:
Tried to create a wallet, ran into an error. How do I create a wallet using Bitcoin Core on Linux that I can then connect with mining?
I tried:
bitcoin-cli createwallet name false false password false false true

and got
error code: -4
error message:
BDB wallet creation is deprecated and will be removed in a future release.
In this release it can be re-enabled temporarily with the
-deprecatedrpc+create_bdb setting

I just finsished IBD earlier and am kinda confused on this.
What does this error message mean?
What is a BDB wallet? What does it mean that its creation is "deprecated?"
What is this future release? Is the Bitcoin Core as downloaded a non-updated thing? Or is it just referring to a future update that will take place once enough nodes agree to it?
Once a wallet is created, where is its info stored on my computer? Is it fully functional from the daemon?

What does this error message mean?

You tried to create a BDB wallet, which is the old type of wallet which is deprecated.
For context, Bitcoin Core supports two types of wallets:

The old type ("BDB" wallets, named after the database format they use)
The new type ("descriptor" wallets, or "sqlite" wallets)

BDB wallets were the only supported type until Bitcoin Core 0.20.0. Since 0.21.0, descriptor wallets have been gradually introduced as a new, more modern wallet format. The plan is that in some future version, perhaps 29.0 or 30.0, it won't be possible to use BDB wallets anymore, which is why since 26.0 the warning you're seeing is present.
If and when this removal of BDB support happens, conversion tools will be provided to convert BDB wallets to descriptor wallets, so no funds will be lost or anything like that. However, since some people still use (very) old versions of Bitcoin Core, after such a conversion, they may be unable to use the wallet in old versions anymore, and they may need new backups, which is why users need to be told that it's happening at all. Furthermore, the commands that work on these wallets differs a bit, which means guides, or even other software on top, may not work on descriptor wallets until it is updated to support these.
You probably just want to create a descriptor wallet (the 6th argument is changed from false to `true):
bitcoin-cli createwallet name false false password false true true

What is a BDB wallet?

A wallet.dat file that uses the Berkeley DataBase format, and with a contents structured in a way that (very) old Bitcoin Core versions can read.

What does it mean that its creation is "deprecated?"

It means that creating such BDB wallet files is still possible in the version you have, but it likely won't be possible anymore in some future version (which is not yet released). Since you may have business practices that rely on using BDB wallet files, it is essential that you're being made aware of the fact that you're doing something that will stop working in the future.
If you really want to create BDB wallet files still, you will need to run bitcoind with the -deprecatedrpc=create_bdb command-line option, to tell it you're aware you're using a feature that is scheduled for removal.

What is this future release?

Maybe 29.0, or 30.0. It doesn't exist yet.

Is the bitcoin core as downloaded a non-updated thing?

Bitcoin Core (deliberately) has no auto-update feature. It'll update whenever you choose to install a new version. You can choose to keep running the current one forever, and BDB will keep working then. However, that also means you won't get bugfixes, new features that get added, or protocol improvements that happen.

Or is it just referring to a future update that will take place once enough nodes agree to it?

Other nodes have absolutely nothing to do with this. Bitcoin Core updates whenever you update it. There are protocol features that depend on multiple nodes speaking the new version, but the wallet file format is a purely local decision that doesn't affect other nodes.

Once a wallet is created, where is its info stored on my computer?

In a file in the data directory for your node, typically with a name "wallet.dat", but it can be named anything. Make backups of it.

Is it fully functional from the daemon?

Yes.

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


text:
If already started Bitcoin Core using the daemon, and I'm in IBD, if I stop it to start it up again through the GUI, will I run into any issues?
Issues like having to restart the IBD, or messing up its download. Or would stopping it be the wrong approach to configuring the GUI?
Additionally, is there a way to use the daemon to check on the progress of the IBD?

Hey CoinZwischenzug, thanks for your questions here! One note for future questions: please try to ask only about one topic, so topics can be more easily searched by other readers of this archive. In this case, "How can I check on progress of the IBD? would have been great as a separate question.

IBD does not need to be done in one session. Bitcoin Core saves its progress as it goes, and when shutdown cleanly, on shutdown. It will resume where it left off on the next start.

Additionally, is there a way to use the daemon to check on the progress of the IBD?

You can use the getblockchaininfo RPC which will tell you the current height and hash, whether the node is IBD state, and the estimated progress, among other info.


text:
What do I need to have set up to have `getblocktemplate` work?
I tried using the command without arguments and it just returned an error code.
Do I need to have some kind of mining software setup? Does that software not already come with Bitcoin Core?
How do I go about getting this software working, either way?

The purpose of getblocktemplate is to return a list of the most profitable mempool transactions and some other data (collectively called a "block template") needed to try and solve the proof-of-work for the next block. This command is used by other software (that doesn't come with Bitcoin Core) that connects to your mining hardware and sends it instructions based on the block templates.
The reason for the error code is that the command requires a JSON parameter with an array field rules with at least the item "segwit":
getblocktemplate '{"rules":["segwit"]}'

Do I need to have some kind of mining software setup? Does that software not already come with Bitcoin Core?

Bitcoin Core does not include a mining capability for mainnet, only for the valueless networks used for testing.
To mine Bitcoin, you need to purchase mining equipment based on ASICs.

You can definitely use Bitcoin Core to generate mainnet block templates, which is what the question is about.

@VojtěchStrnad thanks, yes, but I was addressing the second paragraph specifically. "Does that [mining software] not already come with Bitcoin core". Quotation prefixed to answer to clarify this.


text:
Why does this coinbase transaction have two op_return outputs?
I've been looking at coinbase transactions for fun and I came across one with two op_return outputs..
Does anyone know what the second one is?
Also, I understand the first op_return is used to embed the merkleroot of the witness tree for segwit transactions in the block.
However, I've also seen coinbase transactions with multiple op_returns such as this one.  Is there a specific purpose for that 2nd op_return or is the miner simply using it for their own purpose?

Coinbase transactions have some special rules not shared by other transactions:

only one per block
must be the first transaction in the block
must have OP_RETURN output with witness commitment if block includes segwit transactions
must have only one input
the input must have the "coinbase" field instead of a scriptSig

The "coinbase" field is where miners put the extranonce, commit to a specific blockheight (see BIP-34), and mark blocks to be found by them. Although, miners often collect the block reward in a single output, beside the rules for the witness commitment, the Coinbase transaction has no special restrictions on other outputs. In fact, some mining pools used to pay out mining rewards directly from the Coinbase, see e.g. the Coinbase of 133,471 mined by Eligius creating 919 outputs. As such, the second OP_RETURN output could be anything the miner wants.


text:
What is the function of the payload_checksum field in the Bitcoin protocol
According to the protocol specification at the Bitcoin wiki, each message header includes the  first 4 bytes of sha256(sha256(payload) as a packet checksum. I suppose this checksum is used for packet validation, but I do not see any benefit of this, as Bitcoin utilizes TCP which already has (as far as I know) full protection from lost and damaged  packets. So... why this checksum? Is it to maintain compatibility for future UDP clients?

"Full protection" is a relative term.  TCP packets include only a simple checksum, effectively just the sum of all the 16-bit words in the packet.  See RFC 793 section 3.1.  This is a fairly weak integrity protection mechanism.  The Bitcoin designers may have felt the use of sha256 gave better protection.  It may also, as you say, have been intended to provide forward compatibility for running Bitcoin over UDP or other protocols.  It may even just have been paranoia.

But this weak protection is good enough for other sensitive protocols like FTP and HTTP? They don't include checksums, right? (HTTPS/SFTP does of course, but just plain FTP/HTTP errors could be disastrous too). Thanks for answering though :)

@jori It's not necessarily good enough, but it's what we've got.

I'm going to research the TCP checksum capabilities a bit further and then post back as I cannot believe the designers deliberately choose a bad schema for such an important task. It would be disastrous if using some executable file send across the network using FTP, resulted in unexpected.behavior.

@jori: Bear in mind that the design is almost 40 years old, and it was important that the checksum be easy to compute on primitive hardware. CRCs were probably considered but rejected as too expensive, and our modern cryptographic hashes had not been invented.

Bitcoin originally didn't have this checksum, but Satoshi was having a lot of trouble with various garbled packets on the network, so he added it. It's better than the TCP checksum, and it also covers cases where bad data is sent to the socket. See the post here starting with "I'll take a look a the logs."

@theymos: Thanks for the history.  Since this feature doesn't affect the block chain, it could easily be added without risking a fork.

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


text:
Ip adress tracing lost coins
I read in bitcoin.org that bitcoin is peer to peer means can be traced by ip address.
Actually I don't recall I did join bitcoin but maybe I have these thoughts that could have earned some during my many daily done once activities ... just to clear thoughts that's my ip address 197.52.35.129 .so can u locate any funds I had and forgot about

It is not possible to locate, prove ownership and gain control of Bitcoins from an IP address.

OK thank you...


text:
listreceivedbyaddress - wallet file not specified error
So to start I have very little experience and this may be a simple answer but I can't find it easily.
I suspect that I am using the wrong thing to achieve what I am trying to do.
I'm parsing out the blocks locally to get transactional information. Then I am trying to take each wallet addr with a transaction and check the current balance.
When I run this code I get this error "('Wallet file not specified (must request wallet RPC through /wallet/ uri-path).',)" which makes me think I am not using the correct method.
If I'm not using the correct method, what should I be using?
                received_info = rpc_connection.listreceivedbyaddress(1, False, True, str([output_address]))
                            if received_info:
                                output_file.write(f"  Received by Address Info:\n")
                                for info in received_info:
                                    output_file.write(f"    Address: {info['address']}\n")
                                    output_file.write(f"    Amount Received: {info['amount']} BTC\n")
                                    output_file.write(f"    Confirmations: {info['confirmations']}\n\n")

listreceivedbyaddress is a wallet RPC, it will only provide data on any addresses that are part of your wallet.
Bitcoin Core does not index balances by addresses outside of its own wallet’s addresses. You could use scanblocks which will need the node to have a blockfilterindex, or alternatively scantxoutset. I’m not sure either of these two would be particularly performant, so if you want to scan for a lot of addresses, you may want to look into running an electrum server or block explorer backend such as Esplora.

gotcha, thanks. So I can't use the blockchain locally as a sort of queryable DB?
I will look into Esplora

There is an option to run a txindex, but there is no address index

Could I use scanblocks() with the addr as the descriptor?

Oh, yeah, scanblocks would be a better choice. I forgot we have that now. You do need the blockfilterindex of course in order for that to be available.


text:
CTV real world usage -- How to trustlessly coordinate 1,000 people sharing 1 UTXO? And how many vBytes would be required for such an onboarding Tx?
Lots of CTV talk lately.  I believe I understand the basic concept, which is that, say, 1,000 users could share 1 UTXO, while any 1 of those users can withdraw funds to the main chain at any time.  So the partial UTXO ownership means you still have sovereign, trustless ownership.
It sounds great in theory... but who is coordinating this shared UTXO?  Aren't we also falling back to a trusted solution to coordinate, in all honesty?  It appears more trustless than Fedimint after the UTXO is coordinated and mined.... but the coordination still requires trust, does it not?
Does anybody actually have a trust minimized solution for this coordination of sharing UTXOs?
Also... I'm curious if anyone has an estimate on how many vBytes would be required for a Tx with 1,000 users sharing 1 UTXO.  Any rough ideas or a possible range?

You might be mixing up a couple things. It seems to me when you say CVT, you are referring to OP_CHECKTEMPLATEVERIFY (CTV), a proposed opcode, but your question seems to relate to  JoinPools, could you perhaps clarify what you are interested in?

Correct... referring to CTV.  Thanks for the correction!

I will use Ark, a new layer 2 solution for Bitcoin as a reference.
You can know more about Ark at https://arkdev.info/

It sounds great in theory... but who is coordinating this shared UTXO?

A central party, we call it the Ark Service Provider, or ASP.

Aren't we also falling back to a trusted solution to coordinate, in all honesty? It appears more trustless than Fedimint after the UTXO is coordinated and mined.... but the coordination still requires trust, does it not?

No trust is required with the usage of Anchored transactions.
Also, all on-chain transactions are funded 100% by the ASP.

Does anybody actually have a trust minimized solution for this coordination of sharing UTXOs?

Ark is completely trustless.

Also... I'm curious if anyone has an estimate on how many vBytes would be required for a Tx with 1,000 users sharing 1 UTXO. Any rough ideas or a possible range?

Ark on-chain transactions are regular transactions, with 2 or 3 outputs at most.

CTV can not be used to completely trustlessly coordinate, it relies on central parties hosting servers and off-chain data.


text:
Export a taproot multisig wallet
I have created a wallet, added a descriptors to make it multisig with tr(KI, multi_a(2,pub1,pub2,pub3) command.
Now, I want to import this to some UI but since the wallet doesn't have a private key I am unable to export the same.
Can anyone help how that can be done?

What wallet software are you trying to import to?

Unisat or OKK wallet

Are you sure they support miniscript descriptors?


text:
Multisig for Bitcoin ordinals wallet
I am trying to make and receive transactions on Unisat wallet, but Unisat doesn't support multisig. How do I implement multisig for a wallet that supports ordinals?

You can use Sparrow Wallet for this. It is documented in the official ord documentation.


text:
Is the stale block (its header) accepted only if it extends the existing stale chain tip or it is only necessary that the parent is known?
When I write "accepted" for non-main (canonical) chain blocks, I mean on accepting and storing their headers, not entire blocks. Additional request for an entire block is done once the chain its part of became a new main chain (chain with most total work).
I know that a node only accepts blocks for which it knows the parent (if it doesn't know, block is considered as orphaned and rejected). However, does that parent have to be exclusively one of the chain tips, or the parent can also be any of the blocks from any of the branches (either main or one of the forks)?
For example, we have following chains:
main chain: 100.000th blocks (chain tip: 100.000)
chain_1: diverged from main chain at 60.000th block and has additional 30 block (chain tip: 60.030)
chain_2: diverged from main chain at 20.000th block and has additional 5 blocks (chain tip: 20.005)
Will a block be accepted only if its parent is the 100.000th block of the main chain, the 20.005th block of the chain_2, or the 60.030th block of the chain_1, so chain tips? Or will the block also be accepted if its parent is not some of the chain tips but, for example, the 86.004th block of the main chain, the 20.002nd block of the chain_2, the 60.026th block of the chain_1 etc., so "random" block from some of the chain?
When I say accepted, I mean as a stale block (we got only header). So only validation of PoW and parent hash is done and if everything is accurate, it is accepted. Also, it is checked whether it might have become the new main chain. If so, it becomes main chain and additional checks follow.

Hi Hurry Walk, I have noticed that a lot of your questions are requesting proofreading of your own understanding of concepts. I would like to suggest that you focus on asking your question in the question post, and if you already have an answer yourself, post that as a separate answer post. That way, potential answerers can focus on answering your question instead of proofreading your answer.

I've written a comprehensive question and answer about the entire process of block validation today instead, which I think is more valuable to other readers rather than focusing on your specific misconceptions: https://bitcoin.stackexchange.com/questions/121292/how-does-block-synchronization-work-in-bitcoin-core-today/121293#121293.

@PieterWuille I saw it, its amazing and already started with reading. A lot of quality content. Will take some time for me to read it, but I am definitely enjoying. Already upvoted!


text:
Does Gap Limit Take into Account the Indexing of Master Keys?
For example, if I were to have a 2 of 2 multisig wallet constructed as follows:
wsh(sortedmulti(2,[deadb33f/1000000h]xpub.../<0;1>/*,[deadb33f/0h/1000000]xpub.../<0;1>/*))

Would a standard wallet with a gap limit of 20 have trouble finding the balance because of the 1,000,000 index BEFORE the xpubs(assuming there are 100 sats at index xpub/0/0)?

No. The gap limit only applies to the /* part at the end of the derivation paths. It is the result of the wallet software needing to guess how far to expand the * in order to look for your funds.
The /1000000h part of the derivation path is not automatically searched for, but imported/selected by the user, so the concern of gap limits does not apply.


text:
How do you finalize a PSBT when the last signature is provided by a HWW?
Most device APIs for HWI have a method sign_tx(tx: PSBT) that has a return type of PSBT. If the hardware device I'm interacting with provides the final signature necessary, how do I, from the output of the method, get a ready-to-broadcast PSBT?

Finalizing a PSBT does not require private keys so can be done by any external finalizer that understands the output script.
One such is Bitcoin Core and it's finalizepsbt RPC. This will create the final scriptSig and scriptWitness for each input that it understands that has signatures. If all inputs are finalized, it will also produce the raw transaction hex that can be broadcast with sendrawtransaction.


text:
Transferring Bitcoin to a bank checking account
What app or website do I use to transfer my Bitcoin to my bank account? My Bitcoin is currently in coinbase wallet. Please help. What are the steps? I am having trouble finding the right menus to use to even add my bank let alone make a transfer.

Does this answer your question? How to transfer funds to a bank account. For exact current details, contact Coinbase.


text:
If Bitcoin hits $100,000 how much is 0.01 Bitcoin worth in $?
Just trying to figure out and calculate how much 0.01 Bitcoin would cost in $ if 1 Bitcoin hits $100,000.

I'm voting to close this question as off-topic because it is basic math and unrelated to cryptocurrencies.

While I see your point. I guess if people ask such a question others might search for it and SE has a good visability with search engines thus I will answer it now.

First of all 0.01 Bitcoin is 0.01 Bitcoin which is one hundredth of a Bitcoin.
So if people would be willing to pay $100,000 for one Bitcoin naive economy and math would suggest that they are willing to pay one hundredth of that amount for one hundredth of a Bitcoin which is $1,000.


text:
What is TXID？Is it used to calculate merkleroot
I downloaded the block template where each transaction contains 'data', 'txid', 'hash'. I read in some articles that the Merkelroot is calculated using 'txid'. Is true? Why txid not hash, and what's the difference between them? Before today I always used hash to compute merkleroot and getting the error message "bad-txnmerkleroot". If should use txid, how do I figure out the txid for coinbase that I built?

There are two types of transaction identifiers, TXID and WTXID.
TXID represents the result of a double SHA256 of the serialized transaction form without witness data. It is used to uniquely identify the transaction. TXID is also used to create a Merkle tree and indirectly determine the Merkle root.
WTXID represents the result of a double SHA256 of the serialized transaction form including witness data. It is not used to uniquely identify the transection (although it actually represents a unique identifier). The WTXID is used to create a commitment in a coinbase transaction.
If the transaction does not have witness data, then the TXID is equivalent to the WTXID.
Hash of the transaction is the result of a double SHA256 of the entire serialized form of the transaction, whatever it may be. If the transaction is segWit (if it has witness data), then this hash will be equal to the WTXID and will only be used for the commitment in the coinbase transaction. If the transaction is not segWit (if it does not have witness data), then this hash will be equal to the TXID (but also with WTXID) and will be used as a unique identifier, but also for the construction of the merkle root in the block header.

So I should still build merkleroot with txid? Another question: The block template contains “default_witness_commitment”. Should I put it in coinbase? if yes, which site? Once I have created coinbase data, how do I calculate its txid, double sha256?

@JackGreen Yes, you are building Merkle root with TXIDs. Yes, witness commitment is a part of Coinbase transaction, so you must have it inside one of Coinbase transaction outputs. TXID of Coinbase transaction is calculated in the same way as for any other transaction (double sha256)

The txid or transaction id is a unique identifier of a transaction.
The transaction id is computed by hashing the transaction data twice.
There is one big caveat. For some reason Satoshi decided to revert the byte-order here. I have no clue why he did it. But here we are today and everyone has to revert the bytes.
If it is a segwit transaction the txhash differs from the txid. In this case the txhash includes the witness data and the txid does not. (See this question)

But I sha256 the transaction data twice, the result equals to transaction hash not txid

@JackGreen It happens in the case when the transaction has witness data (segWit transaction). Since hash includes all data (and therefore witness data), while TXID does not include witness data, they will differ.


text:
Getting a feerate estimate via the Electrum protocol
For example, I make this request to the Electrum server:
{ "id": 0, "method": "blockchain.estimatefee", "params": [ 1 ] }

and get response:
0.00254405

Here I get rate btc/kw but I need to convert this to sat/vbyte, so I do 0.00254405 * 1e8 / 1000 / 4 = ~64.
But in fact, this value does not change over time, while mempool.space shows other values. What am I doing wrong?

I don’t think you are conceptually doing anything wrong, it’s simply that the feerate estimate you are requesting is updated less frequently than mempool.space.

Here I get rate btc/kw but I need to convert this to sat/vbyte, so I do 0.00254405 * 1e8 / 1000 / 4 = ~64.

I think that you are mistaken about the unit of the value you retrieve. The Electrum protocol specification for blockchain.estimatefee says that this endpoint returns the "transaction fee per kilobyte". I would therefore interpret the value as [₿/kvB] rather than [₿/kWU] which would mean that your conversion were off by a factor 4.
I suspect that most Electrum Servers use the Bitcoin Core full node they rely on for blockchain data as their source for the feerate estimate. Feerate estimates of Bitcoin Core are less responsive than mempool.space.

So dividing by 4 was superfluous. But 250 sat/vbyte seems to be a very large number, while at the moment the effective fee rate is 80 sat/vbyte


text:
How can I set the derivation path for a multisig across BlueWallet, Electrum and Sparrow wallet?
I just exported a PSBT from BlueWallet and now I'm trying to sign it with the final signature in a multisig setup in Electrum or Sparrow wallet however with both, I am unable to do so:
From my understanding, if I use the sign tool that both these wallets have, and I enter the address that corresponds to the private key needed to finalize the PSBT as well as the PSBT in base64 format, I will be left with a valid raw Bitcoin transaction that I can then broadcast. I MAY BE WRONG ABOUT THIS
Every time I enter the address into the address field, it says "Address is not in this wallet." I believe that this is because the wallets are stuck on a specific derivation path (I looked at the PSBT and the first signer was using the key at m/48'/0'/0'/2'/0/0). Right now, both wallets have a field in settings called Derivation and they are set to m/84'/0'/0' however they are immutable. Anyone know how I can access the 48' part of my wallet? Also, is there any other, better way to sign PSBTs other than doing it manually (if that even works; I am unsure).

I noticed that the path I provided (m/48'/0'/0'/2'/0/0) probably wasn't the path the original signer used. So, from a raw PSBT, how am I supposed to be able to tell which key my wallet should fetch?:
Here's the first half of the PSBT, other half is below:
bBdRZRnAAAAAAAA/////5b6HZFPowozK4ps94NruNKN8cEWntjKrMYoAbRw8i8SAAAAABcWABTAVE+CixByIjfP3qpusoZjvG9hhf/////fQpaZs3N5rivgY++9EPZdigPSCJAOevWeunuviTHatgAAAAAA/////0Kld37OKBDSpOWc48V15ibII74Ugwfow0cY8hYZDO75AAAAAAD/////FdgEE2oNr5DetpIhv4pHG700MV+45OTetoRN3pFRfSsAAAAAAP////+Dr6eKUhBCEK2+0uLiatsvRC/7aCM0clsaQ1n0mUxNdwAAAAA

A/////+luPasbW0PVvGpMp3d5NwYpqog6FiJxBIRnp8An2ShAAwAAAAD/////TEe/3WWPu96yEYZFOuRnuo2S2nWcPFyoez9XbRxxSAIAAAAAAP////9q0YFdD3uVTkW8k94jaJwJalqKDFzzUjzaeBXuZcS1egcAAAAA/////2rRgV0Pe5VORbyT3iNonAlqWooMXPNSPNp4Fe5lxLV6CAAAAAD/////atGBXQ97lU5FvJPeI2icCWpaigxc81I82ngV7mXEtXoKAAAAAP////9q0YFdD3uVTkW8k94jaJwJalqKDFzzUjzaeBXuZcS1eg0AAAAA/////2rR

Hi Myles, I updated the title to form a question. Please feel free to roll back my changes or further edit the title if I didn’t quite gather the gist of your topic. Perhaps it would be helpful to first create a multisig only using one wallet to learn how each operates in a multisig setup to reduce the sources of possible interaction issue as you work towards a multi-software setup.

First, the public key between BlueWallet and SparrowWallet is different, so if you create a psbt in your BlueWallet, it can not be signed in the Sparrow wallet(because of the different private key). Thus, you can create a psbt with your public key generated by your Sparrow wallet, then load the psbt in base64 format, so that you can sign with your private key(generated in the sparrow wallet).

It's a different key because I'm using 2 of 3 multisig. I built the multisig wallet using three HD wallets in BlueWallet and now, I am trying to do the following:
Partially sign the transaction in BlueWallet with one of their keys (done)
Send the PSBT to my Sparrow Wallet that holds one of the HD wallets included in the multisig (done)
Sign the PSBT fully using the SparrowWallet wallet - (not done, I don't know which private key corresponds to the PSBT and I don't know how to fully sign a PSBT in SparrowWallet)

I advise you to try to build the multisig wallet with all sparrow wallets, and sign the psbt again because I guess that the BIPs the BlueWallet used may be different from the SparrowWallet.(Don't send from BlueWallet to SparrowWallet)


text:
Why does bitcoin have so many different address formats?
We know Bitcoin has at least four completely different address formats. They are legacy format, bech32 script, segwit. I know each address format means different transaction types, for example pay to public key hash, pay to script, or segwit payment.
But my question is why do we not just use one type of addresses, such as legacy p2pkh?
In contrast, Ethereum and other blockchains have only one address format. Do these blockchains lack some function that must introduce new address formats?
Or another question, if we only use the original bitcoin address format, aka. the legacy p2pkh. Is it possible to implement other formats' functions?

why not we just use one kind of address type, such as legacy p2pkh?

Because other address types serve different purposes that cannot be achieved with P2PKH.
For example multisig addresses can either provide greater security against certain types of threat or can involve multiple parties in some scheme.
Improved types like P2SH and P2WSH provide better privacy and provide for scaling the Bitcoin network - providing more capacity for transactions. This cannot be achieved using P2PKH.

if we only use the original bitcoin address format, aka. the legacy p2pkh. Is it possible to implement other formats' functions?

Because we use the word "address", people sometimes misunderstand the nature and purpose of a Bitcoin address. It is not a designator of a recipient.
An address is a recipe for a specific type of locking script, it is a complete recipe that contains all the information needed by a payer to construct a locking script that pays the recipient using a script-type specified by the recipient in the address.
If an address could be used with multiple different locking scripts, then in addition to their address, the recipient would have to provide a list of script-types acceptable to them and their wallet software. The address was intended to do the whole of this job.
This is why many people feel that "Bitcoin invoice reference" might have been a better name than "Bitcoin address".

Remember: Bitcoin addresses do not exist in the Bitcoin network protocols and are not used in the Bitcoin network. Addresses, as such, do not appear in the Bitcoin blockchain
Bitcoin addresses are a convenience but not a necessity. The Bitcoin network would work perfectly well if nobody ever used addresses but used some other method of communicating desired locking scripts in QR barcodes etc.
The reason I make this point is not because I want to get rid of addresses but because I think people will be better off to let go of some of the irrelevant semantic baggage associated with the word address from its everyday non-Bitcoin usage.

As an addition, I would like to say that the reason why Bitcoin has more "addresses" comes from the fact that in Ethereum it is possible to achieve (literally to program) all additional functionalities through EVM and the turing-complete language, so it is not necessary to introduce new "addresses" for new functionality (like in Bitcoin).

@LeaBit That's true to some extent, but most new address types didn't actually add any functionality (arguably, only the CLTV and CSV script extensions can be seen as actual new features, and they didn't need new address formats). All the others were advances in efficiency/encoding/security/limits that just required a new script system/structure altogether, rather than just an addition of features (which would typically just involve new opcodes, available in all scripts, and thus usable through existing address types).

@PieterWuille Nice!


text:
How can you remove an input via RBF with Bitcoin Core?
I have an original transaction with two inputs and want to replace it with a transaction that has only one of the two inputs.
Original transaction spending from two addresses:
input 1: 0,5 btc  ⇒  output 1: 0.99 btc
input 2: 0,5 btc

Is it possible to replace this transaction by this one:
input 1: 0,5 btc  ⇒  output 1: 0,49 btc

If that is possible, then how can you do that using Bitcoin Core?

Hi Alice, I edited your post to improve the formatting and included a sentence to describe what I understood your question to be. Please feel free to further edit or rollback if you feel that it doesn’t match your intent.


text:
Why are there multiple payment addresses associated with a private key?
I use the wallet to generate a receiving address A starting with 3 and temporarily name it "A". I export the private key and temporarily name it "X".
I run the command dumpwallet /Users/my/Desktop/1.txt, then open 1.txt. In 1.txt, I find a receiving address starting with bc1 corresponding to the private key "X".

Why does a private key address correspond to two payment addresses?
In the 1.txt file, the receiving address beginning with 3 is followed by 00...... This code should not be a private key. What is it?

Concerning the output of dumpwallet, this is the best answer:
dumpwallet output documentation & explanation?
About your questions:

Why does a private key address correspond to two payment addresses?

Addresses are instructions from your wallet to the paying wallet.
These instructions are divided in 2 parts: a prefix and some string.
If the prefix is:

"1" this means your wallet wants the receiving coins to be locked in a P2PKH script (Pay To Public Key Hash), and the hash of your public key is the string part of the address;
"3" this means your wallet wants the receiving coins to be locked in a P2SH script (Pay To Script Hash), and the hash of the script is the string part of the address;
"bc1q" this means your wallet wants the receiving coins to be locked in a Segwit script, and the hash of the script is the string part of the address;
"bc1p" this means your wallet wants the receiving coins to be locked in a Taproot script, and the hash of the script is the string part of the address.

So, the same exact private key can originate 4 different addresses.

In the 1.txt file, the receiving address beginning with 3 is followed by 00...... This code should not be a private key. What is it?

It's the P2SH address for that private key.

Taproot scripts contain a tweaked public key, not a hash (though the tweak used is derived from the hash of the (set of) scripts in its script tree).

Also bc1q addresses come in two flavors: P2WPKH (which contain a pubkey hash like P2PKH) and P2WSH (which contain a script hash like P2SH).

Thanks @PieterWuille

A private key "X" can generate multiple address types (legacy and SegWit). So, it’s normal to see it corresponding to both a legacy address (starting with 3) and a SegWit address (starting with bc1).
The address starting with 3 followed by 00 in 1.txt is a P2SH (Pay-to-Script-Hash) address. This isn’t a private key but another type of receiving address format used in Bitcoin transactions.
Hope that clears things up!
Cheers,


text:
How to create register system that automatically give each user his own Bitcoin address
I am a complete newbie and I made a website that will have a register system.
I need to know how I can make a wallet that automatically generate a new address for each new register and of course handle the deposit and withdraw.
I searched a lot and did not find an answer.
how can I do that and what language besides java I need to learn?

There's java libarary for bitcoin, bitcoinj. You can check its documentation(https://bitcoinj.org/working-with-the-wallet).


text:
How does subtractfeefrom work?
From the description of Bitcoin Core, subtractfeefrom is a parameter to define which recipient address would opt-in to receive less and contribute to pay the fee
Here is a usecase:
Alex has one UTXO which contains 10 BTC and he sends Mary and Bob each 1 BTC. The transaction fee is 0.5 BTC, so the change to Alex is 10 - 2 - 0.5 = 7.5 BTC.
How does subtractfeefrom apply to above case in DETAIL?
My high level assumption is

Get the required fee for the txn
Deduct this amount evenly from every optin output destination, except the change output, e.g 0.5 BTC / 2 destinations
First optin output destination also deduct by the non divisible amount - e.g 0.5BTC % 2 destinations
check if the deducted output is dust, else continue
adding the total deducted amount to change address

Additionally, what if there is no change output, do we need to create one in this case?

May I ask which RPC you are asking about? I assume it is sendmany, since it has the subtractfeefrom parameter, but there is also subtract_fee_from_outputs on send, and subtractfeefromamount on sendtoaddress.

yes it is sendmany

As you write, the sendmany has the optional parameter subtractfeefrom. It takes an array of addresses which must be a subset of the addresses appearing in the amounts object. Instead of the default behavior of the sender paying for the transaction fees, when any addresses are provided in subtractfeefrom, the transaction fees are deducted in equal shares from the listed recipients.
Under the hood, Bitcoin Core performs coin selection as if the transaction did not cost fees using the actual values of UTXOs instead of their effective values. After assigning the leftover amount to a change output, the fees for the entire transaction are calculated and deducted from the recipients listed in subtractfeefrom in equal shares. If the amount does not divide cleanly, any remainder is deducted from the first listed address, i.e. if the transaction fee amounted to 800 sats and there were three recipients to deduct the fees from, the first would pay 268 sats and the latter two would pay 266 sats.
As the combination of SFFO and attempting to find changeless transactions has caused several bugs in the last year, Bitcoin Core will always create a transaction with change when any variant of subtractfeefromoutput (SFFO) is used. Incidentally, if you want to empty a wallet completely, perhaps consider using the sendall RPC instead.
Overall, SFFO is a huge pain in the neck as it turns a number of the general assumptions about coin selection and transaction building on its head. If you are looking to implement something like it, I would suggest that you do not attempt to copy Bitcoin Core’s approach.

Oh, i was trying to copy their approach, but some part is not quite easy to understand, would you mind to explain a bit more on how does the effective rate come from? in addtional, when i take a look on the CPP code, it seem it doesnt create change if the SelectCoins process doesnt require, and afterward, it only subtract the fee from recipient if fee_needed - current_fee, i have no idea what is diff by fee_needed vs current_fee too

so in that case, if the change doesnt create, and fee_needed - current_fee > 0 , means recipients receive less, and fee increase, this is not making sense anyway

Here is a topic that explores effective value of UTXOs as a concept. The gist is that you know how much fees you will be paying to spend a UTXO when you know the feerate and the output type. You can then deduct the fee from the value of the UTXO in advance of coin selection and makes it much easier to figure out whether you have selected enough. ••• 2. The selection_target in Bitcoin Core is composed of the money needed to create the recipient outputs, plus the fees for the fixed size parts of the transactions, and a budget for change.

The coin selection methods that create changeless transactions are disabled when the user specifies SFFO. Bitcoin Core will always create a transaction with change if the fee is paid by recipients. ••• 4. Usually, coin selection will consider UTXOs at their effective value, i.e. the fee for every UTXO that is selected as an input is already accounted for. When SFFO is active, the UTXOs are counted with their full value and the fee is calculated in the end, before it is deducted from the recipients. That’s why fee_needed - current_fee will not be 0 at that point.

Thank you for the information, i will take a deep dive!


text:
Why don't Bitcoin mining operations grow exponentially?
I went to Bitmain's home website one day when I saw the S21 Hyd.  I ran calculations on that and found out it could pay for itself every 4 months (after power bills).  So, how come Bitcoin mining operations don't double over a specific time period e.g. every 4 months?  Assuming you have a good paying job, and you just want to get a lot of miners until a point, after only three years, you have 1023 miners, making 25,000 dollars per day.  And then in another 3 months this turns to 50k, and so on.  What controls the growth of Bitcoin mining operations?

That is exactly what is happening: Bitcoin’s hashrate is growing exponentially, except that the growth is limited by the speed at which new hardware is produced and deployed. (A line with a positive slope in a logarithmic chart indicates exponential growth.)
via bitcoin.sipa.be
The network’s hashrate has increased by 37% since May with 11 adjustments increasing difficulty and only three adjustments reducing difficulty.

via btc.com
As long as mining is profitable, miners invest in additional hashrate to corner a larger share of the entire mining reward. Hardware manufacturers come out with more efficient models that replaces prior models. Miners with less profitable operations go out of business or shut down their less profitable hardware.
I would be a naïve miscalculation to expect that your hardware will pay for itself in four months, though. Just as you are deploying your new hardware, so will your competitors. Your profitability will decrease significantly in the coming four months compared to today’s network outlook, and you will need to adjust your expectations accordingly.

I ran calculations on that and found out it could pay for itself every 4 months (after power bills).

I'm rather skeptical of that. My first Google result was here. As of 27 Nov 2023, it's listed as having a gross yearly income of $9,444.62, electricity costs of $5,557.25 at 0.12/kWh, and net of $3,887.37. The lowest price listed is $5,368.73, for 497 days or 16.5 months to pay back.
And this is based on spot prices. Just because the numbers at the moment work out to be profitable, doesn't mean that they will be in the long run. And 16.5 months is a somewhat long run to be depending on profit/expense numbers to be holding steady. And this website it's not available yet, so if it really is profitable, then once it does become available, the hash rate, and hence the difficulty will spike upwards. Furthermore, I suspect that there are costs that aren't being factored in. The nature of the difficulty mechanism means that absent a breakdown in basic economics, the net risk-adjusted profit is driven towards zero.


text:
Processing bitcoin reward block's input transaction
I'm parsing the block response of my bitcoin node and everything is going ok.  The only thing I don't understand is how to parse the input transaction of the block reward.
This is the array that I see as the signature_script  of the 4th block of the Bitcoin blockchain, which has only one transaction and is the signature_script which each byte is in it's decimal form: <<4,255,255,0,29,1,3>>.
What does this mean?  I could not found information about it in the documentation.

Related: https://bitcoin.stackexchange.com/q/114846/13866

Possible duplicate of https://bitcoin.stackexchange.com/q/20721/5406

This is the scriptSig of a coinbase transaction (the first transaction in every block is special; it doesn't actually spend anything but brings new coins into existence).
Coinbase transactions have a number of special rules that apply to them:

They must be the first transaction in a block, and cannot occur anywhere else.
They must have exactly one input, for which:

The prevout must have hash 0000...0000 and vout index 0xFFFFFFFF.
The scriptSig must be between 2 and 100 bytes long, but otherwise has no meaning. Miners typically use this space to store what is called an extranonce, to be able to grind through more hashes per second then the block header nonce space allows for.
Since the activation of BIP34 in 2012 (which your block predates), the coinbase scriptSig must start with a push of the block height.

They can claim the block's subsidy and all fees paid in the block (implicitly).
They must have 1 or more outputs like every other transaction, determining where the mining rewards get paid to.

So in short, this script has no actual meaning, except for being space miners can fill in as they wish.


text:
Are the characters 0, O, I, l really not allowed in address?
I need to be able to validate BTC addresses. I keep reading how characters 0, O, I, l are not allowed to avoid visual ambiguity.
That said, I've run into a couple of address which contain these characters, and they seem to be fine:
bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq
bc1qvtrafpjnl3ygg2w40eldlq7ggdgg8wuu3nqcxe
So what's going on with these? Do these rules not apply to bc1 address? Are they more of a recommendation than a requirement? Thanks

There are two different encodings being used for Bitcoin addresses.
Native segwit addresses are encoded using the Bech32(m) encoding. Bech32 uses the 32 symbols 023456789acdefghjklmnpqrstuvwxyz to encode data. On mainnet bitcoin native segwit addresses start with the human readable part bc and the separator 1. The prefix is different on test networks.
All prior addresses use Base58. Base58 uses the numbers from 1-9 (excluding 0) and all letters of the English alphabet in uppercase and lowercase, excluding capital O, capital I, and lowercase l, because 0 and O, as well as I and l are easy to confuse in many fonts. This leaves the 58 symbols: _123456789ABCDEFGH_JKLMN_PQRSTUVWXYZabcdefghijk_mnopqrstuvwxyz. (Omissions are included in the symbol line-up as underscores in case the letters in the text were hard to parse out of context of the order.)

As I understand it, those characters, when lowercase and uppercase, can be confused with numbers or other characters like 0 and o. They really don't have much difference in appearance

That is correct, but not an answer to the question.


text:
If I lose my Bitkey hardware wallet, and they stop making them, what happens?
If I get a Bitkey wallet and I lose it, I can simply get another wallet and get my crypto back. But what happens in 10 years time if Block go out of business, and they stop making the wallet? Can I still get my crypto back?

Since it uses a 2 of 3 multisig wallet, you need any two of the following to have (or regain) control of your funds:

Mobile key - A key stored in the Bitkey app on your phone.
Hardware key - A key stored in the hardware wallet device.
Server key - A key stored in a server operated by Block Inc.

If you lose the second and the third is unavailable, you will lose your ability to spend money.
The only obvious way around this is to have a backup of the hardware key, know how to set up a different wallet application as a 2 of 3 multisig wallet and have any other relevant information such as derivation paths.
The only way I think you can satisfactorily prove you can recover from that scenario is to actually practise recovery and use non-Bitkey software to make a test transaction spending a small amount.


text:
Will Schnorr Multi-signatures completely replace ECDSA?
I stumbled upon the fact that schnorr signatures will most probably replace the current ECDSA system in a future BIP.
Is it worth learning about ECDSA or this will become obsolete/useless/confusing knowledge ?
Or should I go straight into schnorr signatures, for example how will it impact a model like this

Schnorr signatures will not replace ECDSA. Schnorr signature verification is expected to be implemented with the Taproot soft-fork using SegWit witness version 1. This means only outputs that are locked in v1 SegWit version are expected to produce a valid Schnorr signatures.
ECDSA will continue to be used for spending current non-SegWit and v0 SegWit outputs. All outputs having the OP_CHECKSIG opcode will continue to use the legacy ECDSA signing algorithm and verification.
So, understanding ECDSA is important for understanding the signature verification behind spending all outputs that are not native v1 SegWit. According to txstats.com only over 2% of all the BTC value locked belong to native SegWit scripts, that too after almost 2 years of implementation. So it can be safely assumed that V1 implementation might not completely replace all current output locking scripts, needing you to understand ECDSA signing algorithm as well if you plan to build products that would accept Bitcoin that require ECDSA signatures to spend.

"a soft-fork [...] cannot remove ECDSA"  This is phrased confusingly.  I think you're trying to say that we can't allow legacy OP_CHECKSIG operations to be satisfied by a schnorr signature using a soft fork, which is correct.  However, when I first read your sentence, it sounded like you were saying that we couldn't remove ECDSA altogether via a soft fork, which is incorrect---we could make legacy OP_CHECKSIG always fail via a soft fork since that would be simply making the rules more strict.

@DavidA.Harding Yes you are correct. I think that was a poor choice of words on my part.


text:
Passing incomplete information to an SPV node
I am wondering how SPV handles the following scenario:

A transaction has been confirmed by some block X, and funds address y.
At some later block, the transaction's output are spent again
SPV node queries the balances of y, the full node peer returns the answer along with the merkle proof for block X.
But.. the answer doesn't give you the most up to date response, because y funds were depleted in a more recent block...

I know some ideas like UTXO commitments were around but I am not sure that they were ever merged into bitcoin.
So, was this problem ever solved? Or maybe no one tended to it because it was concluded to not be so bad?

This is a a known shortcoming. The SPV protocol does not protect against omission attacks.
An SPV wallet can request a proof that a given tx is present in a given block, and that a given block is part of a given chain. However, it is not possible to prove that the node isn't omitting a transaction the wallet would like to know about without providing the entire block data for each block, at which point you are essentially a full node.
Wallets avoid this by connecting to multiple nodes - as long as there is one honest node in that connection pool, the wallet will receive up to date information.

This isn't unique to SPV nodes but can affect any node. The simple fact is that Bitcoin relies on up-to-date information about blocks in order for you to make meaningful decisions about the finality of a transaction. No kind of UTXO commitment could fix this because you might not receive the most up-to-date UTXO commitment.
Whether y has had an attempted spend is not something of importance. What you need to know is whether y has been confirmed spent, meaning, has been included in a block, and some amount of proof-of-work has been done to limit the possibility that this could be undone by a minority of network participants.
You need to listen for new information to get these confirmations. If you are selling goods or services for Bitcoin, then you need to have some N > 0 confirmations before you part with any goods because there exists the possibility that y could be double-spent, but this possibility declines rapidly with each new confirmation.
To make sure that you aren't a victim of fraud, you should get information from multiple distinct sources to ensure that you are not subject to an eclipse attack, where one party, or a group of parties colluding deliberately provide you false or incomplete information in attempt to defraud you.


text:
How are UTXO forwarded to other addresses?
this is a pretty general, conceptual question. I feel I do not yet completely understand the blockchain transaction dynamics.
Let's say, we have A, B and C trading on the Blockchain:

A has previously transferred 10BTC to B. So B has an unspent transaction output
(that it can spend) referenced by the address of A.
Now, B wants to pay 5BTC to C and does so by using the UTXO that it has from A's earlier transaction and routing it to C.
So, B forwards the UTXO with A's address to C and also gives 5BTC change to himself.

So, now, doesn't the transaction list look like this?
Inputs:

address_A 10BTC

Outputs:

address_C 5BTC
address_B 5BTC

Now, to me this seems correct from B's view, but it actually looks like A has transferred money to C and B, instead of B transferring money to C. I guess my understanding is wrong then, because it cant work like this. So where is my error?
From the view of C, shouldn't it look like this:
Inputs:

address_B 10BTC

Outputs:

address_C 5BTC
address_B 5BTC

Otherwise, also C would have again the unspent output of A and this output from A would sort of be forwarded again and again.
Don't judge me for my bad understanding please :D, if there is any good reads that you can recommend that would be great.
Thanks!
Best,
JC

A first thing to correct is that UTXOs are not referenced by address, but by the txid that created them. The addresses are purely a human abstraction about locking conditions to help think about ownership.
So in your example what happens is that in the initial transaction tx0 created by A, B was credited with 10 BTC. Assume that transaction only had one output. That means that there is now the state of the UTXO is:

tx0:0 (10 BTC, spendable by B)

When B now wants to pay C, he creates a transaction tx1 with input (tx0:0, (signature by B)) which consumes the UTXO listed above, and has outputs (tx1:0, 5 BTC, (spendably by C)) and ((tx1:1, 5 BTC, (spendable by B)). Note that the tx1:0 and tx1:1 are not actually stored in the transaction here; they're implicit as the 0th and 1st output of tx1.
The state of the UTXO set is now:

tx1:0 (5 BTC, spendable by C)
tx1:1 (5 BTC, spendable by B)

UTXO are uniquely identified by their outpoint. An outpoint consists of the id of the transaction that created the output and the position in the output list.  As transaction ids are the full transaction body's hash, they are collision resistant, and as each position in the output list can occur only once, outpoints can be expected to be unique.
E.g. the second output of this random transaction I found on a blockexplorer would be c0352a…21bf50:1. (The first output is c0352a…21bf50:0.)
Now when you want to spend a UTXO, you would reference which one exactly in an input by its outpoint. The UTXO doesn't get forwarded, but rather a transaction orders the Bitcoin network to destroy/invalidate/consume all the UTXO listed in the inputs and to create new transaction outputs as specified in the output list.

EDIT: I wrote this hours ago, but apparently forgot to hit the post button. There are now a couple great answers, but I'll still post this anyways.

A has previously transferred 10BTC to B. So B has an unspent transaction output (that it can spend) referenced by the address of A.

UTXOs are not 'forwarded to an address', they exist until they are used entirely as input(s) in a new transaction, and that transaction may create new UTXOs as outputs. Each transaction entirely destroys its inputs, and creates new outputs (new UTXOs). Note that even within a transaction, it may be unclear which inputs relate to which outputs.
So when A spends a UTXO to send coins to B, they will create an entirely new UTXO (that B owns) to do so. Etc.


text:
Why can't Grover's algorithm be used for bitcoin mining?
Similar questions have been asked before:
Can quantum computing improve Bitcoin mining?
Can a Qubit Miner ASIC device be created and what would its impact be on the mining community?
However, none of these answers give me a clear indication as to why Grover's algorithm can't be utilized for bitcoin mining. If the current difficulty of bitcoin mining is about 15,466,098,935,554 (approximately 2^44), which means that it would take about 2^44*2^32=2^76 SHA256 hashes before a valid block header hash is found.
However, by implementing Grover's algorithm, it would take only sqrt(2^76)=2^38 hashes to discover a valid block header hash. A 38-qubit quantum computer should be sufficient in this case. Quantum computers of this size have already been built (the largest quantum computer is 72 qubits, to my knowledge).
Therefore, why isn't it feasible to use a quantum computer to mine bitcoin by implementing Grover's algorithm? Did I get something wrong? I'm not too familiar with encryption and quantum algorithms, so please correct me if I missed something......

There's no operational quantum computers that can do anything faster than classical computing, you've been deceived by marketing.

"it would take only sqrt(2^76)=2^38 hashes to discover a valid block header hash. A 38-qubit quantum computer should be sufficient in this case."  You are severely confusing time (hashes) with space (qubits) here.


text:
What are ASIC miners actually doing?
I'm trying to understand Bitcoin mining (software-wise), and I wonder how ASIC miners are different? I'm going through this minimal Bitcoin miner Github repository.
Which part of Program.cs are ASICs optimizing (I guess Program.cs line 90)? Where can I read more about in-depth working of miners? Is there any documentation?

The term ASIC is not associated with software but hardware. It means Application-specific integrated circuit and we should call it processor. For comparison with FPGAs, see for example Xilinx's site.
Typically you need some mining software like cgminer or bfgminer. With these software you should use various types of "processors" to mine with. The most typical are:

CPU (which is probably CISC)
GPU through OpenCL (most likely, see this answer)
ASIC unit which is designed only for computing SHA-256 hashes

So ASIC chips are not doing the optimization, just working with hashes faster than other chips.

I have ASIC miners  SHA-256  in one and Blake ago in the other.
I noted they both mine DCR coin.
One is D9 miner the other is Bk-B miner.
I tried mining alt coin Verge with both and got interesting results.
They both read blocks found on verge mine sites.
The Innominer with a insane count number.
See the picture. Only issue is the site recorded no blocks found so I did no make an dime with testing.  I would think with some testing and software update for the coin type for each They could bring in the big returns rather fast returns.

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


text:
Can I be rewarded for discovering, creating, and proving bugs on Bitcoin?
There has never been a remittance history to this address.
https://www.blockchain.com/btc/address/1JqPFnGPhHhy54zJKmC1MPiczzgFjCmzE9
public key : 02f51f8d0c4dc4a5338bef745098e6f6364f8936fee6aa5a9d4ab0c214e7cdd727
It has a balance of 340 bitcoins.
I am not the owner of this bitcoin.
However, you can create a transaction with only the public key.
I can make this kind of transaction infinite.
You can check the rsz value with this program.
https://github.com/Sean-Bradley/ECDSA_secp256k1_JordonMatrix_nodejs/blob/master/getPubKeyFromRSZ.py

R = 0xf8eb13edf4663f68fe635bdd7222c79d964099b4bb7595a53e1c22f988c1cfa2
S = 0xd83fd6c056a6eae6f76c492f7791fdb83336a5b796aa95656159e161cf1d03bc
Z = 0x72ee6ef84536396d0b655396281876a81cd998bb27dde49171785a6c4c45e6e7
R = 0xb4684517444a86cbc7a11eeda7aea984755dbb624d57907f09dcc4e47bd648cd
S = 0xcdffc4fb64e5acd079b2c3de7c8c122a7a4cdfb9f70cc02eef54452bbf5e7b82
Z = 0x873b1235044c5b38a24cfa941cb6347ba6038771d54b672e03d812fc291dffa2
R = 0x4e3a352bd5f7598ddf580f5e2181ea3faf33e8186dff84aa462d90b3b37e7371
S = 0xaad1fce91c3326b6ad8dc1c0a0d41625ec23b97f4f50092d94b36f22b3c1122d
Z = 0x8625e67ceca36f11d315be232fe86bef50c4d8a6bcf9fc4adb7120fb671bc827
R = 0xd875063a0b9e9aa30d58f8ac3e39d1f6695a5d04deea0a8f1d6dcbc96a3a3d22
S = 0xbe27760132ba69321cb938ab931fd78ce9c944644505b48ae170e8171ccfe761
Z = 0xdeead39249eb7d02856de81723d193727a599db0a156dbf5bff60427d17f5a95
R = 0x29e690606edf3d7dc5b2e4f83c2c7ea8924cb0911792514c1912789cc3dde563
S = 0xc7722f325ce71add08eb51e9edfae276d9c164d298d8355c6cf75359e5cf7eb3
Z = 0x5c7abfcb68f3e4d0320c760a8430a52c90d8c2ee3795878b0b308bfaa310082f

Yes, finding bugs in Bitcoin would be valuable. However this doesn't seem to be one.
What's shown here is a series of supposed "signatures" with the hashes of messages they supposedly sign. However, a cryptographic signature is only meaningful in the context of the message it signs.
To verify a signature, you need three inputs: 1) the message, 2) the public key, and 3) the signature. Generating a "signature" that corresponds to a public key is trivial if it doesn't need to match a message, but without the message it cannot be verified to be a valid signature.
To create a Bitcoin transaction, you need to sign a specific message, namely the transaction. If you could do that, that would be a problem, however, that's not what you've shown here. Rather than the message, you only provide the hash of a message of which you do not know the preimage—a parlor trick.


text:
Denial of Service during Initial Block Download
I'm certain this has an obvious answer, but I haven't been able to find it -
Since it doesn't cost a transaction fee to request block data from another node, what stops an attacker from (D)DoSing a node with spurious GetBlocks?
Relatedly: why would a node bother to spend its bandwidth fulfilling GetBlocks requests when it would help a competing node?

Nodes don’t compete. It is in the interest of node operators to spread the current state of the blockchain to help that all participants converge on a shared state. For many node operators, their bandwidth allowance exceeds the demand they encounter, so sharing the blockchain is basically free to them. You could absolutely request the entire blockchain from one peer over and over again. If this attack were to spread, people would probably limit the amount of bandwidth they permit to be used for uploading by setting the startup option maxuploadtarget.


text:
What are the DER signature and SEC format
I often see those 2 elements in bitcoin documentations and tutorials but I have not yet find a proper definition on the internet for DER signature and SEC format.

For reference, DER encoding is defined in ITU-T X.690 (part of ASN.1)

DER
The Distinguished Encoding Rules (DER) format is used to encode ECDSA signatures in Bitcoin. An ECDSA signature is generated using a private key and a hash of the signed message. It consists of two 32-byte numbers (r,s). As described by Pieter here the DER signature format has the following components:

0x30 byte: header byte to indicate compound structure
one byte to encode the length of the following data
0x02: header byte indicating an integer
one byte to encode the length of the following r value
the r value as a big-endian integer
0x02: header byte indicating an integer
one byte to encode the length of the following s value
the s value as a big-endian integer

Note that the r and s value must be prepended with 0x00 if their first byte is greater than 0x7F. This causes variable signature lengths in the case that the r value is in the upper half of the range (referred to as "high r"). Signatures with high s values are non-standard and usually don't appear in the wild.
Also note that in rare cases r or s can be shorter than 32 bytes which is legal and leads to shorter signatures.
Note that in bitcoin transactions a byte is added at the end of a DER signature denoting the SigHash type used.
SEC
The Standards of Efficient Cryptography (SEC) encoding is used to serialize ECDSA public keys. Public keys in Bitcoin are ECDSA points consisting of two coordinates (x,y). x and y may be smaller than 32 bytes in which case they must be padded with zeros to 32 bytes (H/T Coding Enthusiast). Bitcoin uses two formats, uncompressed and compressed:
Uncompressed:

0x04 byte: header byte to indicate ECDSA point
the x coordinate as a 32-byte big-endian integer
the y coordinate as a 32-byte big-endian integer

Compressed:
As the coordinates (x,y) must satisfy the secp256k1 curve equation y² = x³ + 7, the two possible values for y can be calculated from the x value. Thus, we can express a public key just as the x coordinate in combination with an indicator which of the two y values to use.

0x02/0x03 byte: header byte to indicate compressed ECDSA point, 0x02 for even y, 0x03 for odd y
the x coordinate as a 32-byte big-endian integer

The above is more comprehensively explained e.g. in Jimmy Song's Programming Bitcoin: Ch4. Serialization.

Great answer thanks, what are r and s derived from?

@Dominic: That’s the signature. The signature uses the Elliptic Curve Digital Signing Algorithm and the secp256k1 curve to commit to a Bitcoin transaction as the message. The “r” value commits to a random curve point, and the “s” value commits to the transaction and the random point in a manner that requires the knowledge of the relevant private key in the construction. See e.g. Stepan Snigirev’s blog post here for a longer explanation: https://medium.com/cryptoadvance/how-schnorr-signatures-may-improve-bitcoin-91655bcb4744

There are different formats used to encode public keys and signatures into binary (octet-streams). They are defined in Standards for Efficient Cryptography 1 (SEC).
A public key is a point on an elliptic curve, consisting of an x and y coordinate. There needs to be a standard way for serializing these parts and deserializing them later. The standard defines a uncompressed and a compressed format for this serialization. Roughly, the uncompressed format uses the prefix byte 0x04 followed by the serialized x coordinate, followed by the serialized y coordinate. The lengths of x and y are determined by the curve. For bitcoin, the curve secp256k1 is always used, so the coordinates are 32 bytes. The resulting uncompressed public key is 65 bytes total.
The compressed version prefixes the octet-stream with 0x02 if the y coordinate is even and 0x03 if the y coordinate is odd. The x coordinate is serialized after it, resulting in a 33 byte public key. This information is sufficient because the y coordinate can be recovered if x is known and the sign is known. (Technically, we don't need the sign either).
Signatures consist of an r value (the x coordinate of a point on the curve), and an s value, which is an integer (32-bytes for secp256k1). The signature can be encoded in just 64 bytes in this compact form.
The paper previously linked also gives descriptions of these formats in ASN.1 (Abstract Syntax Notation 1). This is a textual interface description language which has been used to describe protocols for interoperability for a long time. Another standard, DER, or Distinguished Encoding Rules, describes a process for serializing data into octet-streams according to the ASN.1 specification for the data type.
The ASN.1 for signatures is (simplified):
ECDSA-Sig-Value ::= SEQUENCE {
    r INTEGER,
    s INTEGER
}

According to the DER rules: a SEQUENCE is of type 0x30 and is followed by a length (1 byte for length < 128), then the data for the sequence itself. INTEGER has type type 0x02 followed by its length, followed by the integer in binary. These integers are also signed, which means that if their value is >= 2^31 an additional zero valued byte must be prefixed to them. The resulting DER encoding for a Secp256k1 signature looks something like (assuming 32-byte r and s):
0x30 0x44 0x02 0x20 <r[32]> 0x02 0x20 <s[32]>

As you can see, this is pretty wasteful compared to the concise 64-byte serialization of (r,s). The uncompressed version of public keys is also very wasteful because every byte in a transaction is valuable. The Segwit upgrade to bitcoin introduced some restrictions on which formats can be used, and additionally, the upcoming Taproot upgrade will require 32-byte (x-only) public keys, which are not part of the SEC standard.


text:
How does RBF (BIP 125) behave, when the unconfirmed UTXOs are being spent?
Let's assume we broadcast transaction A (TXA), signalling Replace-By-Fee as defined in BIP 125. We pay 1 sat/vByte for the transaction.
One of the outputs goes to Bob. But Bob immediately spends his output, even before TXA is confirmed. Let's call this spending transaction TXB. TXB uses 100 sat/vByte.
Now, with still no transaction being confirmed, we replace TXA with a 3 sat/vByte fee transaction (let's call the replacement transaction TXA2). What happens in this case?
I can think of the following outcomes:

Spending of unconfirmed RBF UTXOs is not allowed. TXB is rejected by the other nodes.
TXA2 gets rejected, because there is already a spending transaction.
TXA2 gets rejected, because the fees of TXA + TXB are higher (in total sat/vByte) than the fees of TXA2. But if TXA2 pays a higher sat/vByte than TXA + TXB, it replaces TXA, and TXB becomes invalid.
TXA gets replaced with TXA2, TXB becomes invalid because the parent transaction has been replaced. The requirement is only that TXA2 pays more than TXA (in alignement with  BIP 125 rules), what TXB pays in fees doesn't matter.

related: https://bitcoin.stackexchange.com/q/106708/5406

In order to be valid for replacement the challenger must have a higher feerate than (all) the conflicting transactions(s) and pay more absolute fees than (all) the conflicting transaction(s) and all its(/their) descendants.
In your example whether TXA2 will be accepted and replace TXA + TXB depends on the size of each (to deduce their absolute fee).


text:
How much will Taproot boost Bitcoin's transactions per second?

Currently, the bitcoin network does about 3-7 transactions per second. How much can taproot theoretically increase that?

Assuming a current throughput of 5 transactions per second, we get only about 150 million transactions per year. How can a population of 8 billion adopt the bitcoin standard if everyone wants to hold their own key?

I don't think it really matters how many transactions per second Bitcoin can do.  No need to focus on that.   Bitcoin is able to settle 'quickly enough' or 'cheaply enough', depending on what you personally want.   There is absolutely no problem having slow transactions IMHO.   Transactions are still far faster AND easier than transacting in bullion.


text:
Do exchange rates between countries' currencies have an influence on Bitcoin exchange rates?
Are the exchange rates of each country a factor in the worth of a Bitcoin? Is the use of Bitcoin similar to traveling to another country and having a exchange rate between paper monies?
Basically, are bitcoins affected by the exchange rates of each country or the web exchange?

Bitcoin follows very closely to USD and RMB, because US and China are the biggest players in the bitcoin market now. You can see the trade charts here: http://bitcoincharts.com/charts/volumepie/
Hence US and China exchange rates will affect the worth of Bitcoin.
In regards to travelling, the merchant accepting Bitcoin will list prices in their local currency. If you pay with Bitcoin, they will use the exchange rate found on one of the exchange networks (e.g. mtgox)

In this situation I can only give my own experience.
The exchange rates most certainly affect my decision on which exchange I would use to wire money to to make a purchase.
Is the USD weak against GBP? I would wire to an exchange which only works in USD and converts all money at market rate.
Is the EUR weak against the GBP but USD is strong on the GBP?? I would wire to an exchange which converts to EUR at market.
So yes it does cause some peripheral effects, if everyone is doing the same as me it will cause an effect in the value against specific fiat currency.
Im in the UK for reference.
I hope this at least partially answers your question.

Theoretically if the Bitcoin market was 100% efficient the exchange rate of fiats should be the same in Bitcoin pricing. That is definitely not always the case, and if someone has a global bank accounts they may be able to take advantage of these arbitrage opportunities.
In the last 2 years this gab has tightened which is expected. Here is a current example
Looking at the Canadian dollar. (Ignoring MTGOX)
Virtex = 875 CAN to buy 1 bitcoin
BtcStamp = 861 USD buy 1 Bitcon
CAN To USD conversion 90.5 CAN to USD
All prices as of the time of this post. (Ignoring commission and conversion charges)
So if you bought 10 Bitcoin in Canada = $8750 CAN invested
Sell in the USA 10 Bitcoin = $8610 USD
Convert to CAN dollars at 0.91 = $9461 CAN dollars
So you would have a $710 profit (Approx 8%) bringing the funds back to Canada less commission. DO this enough and the spread should theoretically tighten to not be profitable.


text:
Do we know who runs the big mining pools?
After looking at the hashrate repartition https://blockchain.info/fr/pools.
It seems to me that bitcoin is quite centralized, and that two big actors (mining pools company who run the bitcoind server) like BTC guild and GHash.IO suffice to obtain the mythical 51% computing power, allowing various kinds of attacks.
How do we know that these two guilds are not the same person, or will not collude?
In the event that such collusion happens, and malicious double spending* occurs or other attack occurs, how do we detect it? What happens when we do detect it?
*Double spending doesn't have to be malicious: https://blockchain.info/fr/double-spends

This list is not exhaustive, and the information is based on bitcointalk and coindesk discussion and articles. As of 1 Dec 2014, based on pool stats from few websites including https://blockchain.info/pools
GHASH.io is at 13 % , it is based out of Europe.
GHASH is closely related to CEX.io BitFury, Jeffrey Smith is the technical person at CEX.io.
Eligius 4 % is operated by Luke.Jr
Discus Fish 25%  is based out of china & coowned by Wang Chun.
Megabig power 2% in Washington operated by Dave Carlson.
KNC 8% is based out of Sweden , Sam Cole & Marcus Erlandsson.
Cointerra 2%  is based out of Texas. Timo Hanke & Ravi Iyengar.


text:
How can vulnerabilites in bitcoin be responsibly reported?
I am wondering if someone discovers a bug/exploit in Bitcoin software or protocol, who should it be disclosed to? Who is the authority? What would happen if the bug went public? Has it occurred in the past?

Information on current (ie, not past/public/resolved) security issues should be sent to the private bitcoin-security@lists.sourceforge.net mailing list.

Thank to your address I found the procedure to follow described on http://bitcoin.org/fr/developpement


text:
What wallet should I use to collect the mining payout from multiple machines?
I am trying to set up my Debian Server so that I can join a mining pool.
I already know that I am going to use cgminer for the mining software because it will work with the server format (command line).
What I am not sure about is what type of wallet I should use and how I would link multiple machines to one wallet (I want to use my home computer as well).

Please be aware that unless you have free electricity, mining with anything but ASIC hardware has become unprofitable. You might want to read the following question before continuing: http://bitcoin.stackexchange.com/q/1452/5406

The title and the content of this question didn't match at all. The title had lured 5500 views already most likely only for visitors to find out that it has nothing to do with what they were were looking for. I've therefore edited the title to better align with the content of the question.

Regardless of what wallet you use, it's entirely unrelated to your mining except as a payout. The address you withdraw to can be in a wallet anywhere (even offline).
P.S. You should really consider upgrading to BFGMiner instead.

thanks.  but why BFGMiner instead?

BFGMiner is much more stable, uses standard Linux drivers, a more informative text-user-interface (TUI), has better GBT support (including solo mining), support for more devices, etc...

I ended up using that.  But I cannot get it to recognize any of my server's devices.  The server is a Dell PowerEdge R200 and it has an AMD ATI ES1000 embedded card but BFGMiner can't find it and I don't know why. Could it be a problem with drivers or OpenCL?

Probably, but note that mere GPUs and CPUs can only emulate real mining devices, and will cost you money to run, not make any.

An online wallet would work well. I know this question is old but I thought I'd try for a more current answer.
The reason I suggest online wallet, is because you can access it from any computer, browser, smart device, etc.
CoinBase is a great option because you can buy and sell Bitcoin, Ethereum, and Litecoin... so if you mine it and want it in USD ASAP set your miner up with a CoinBase wallet.
Another online wallet is the Blockchain.info's wallet.
These both are great wallets I use and trust, and they also have great mobile applications.
If you'd like to trade your bitcoin on an exchange, I'd recommend either opening a CoinBase/GDAX account (they are linked so if you have money in your CoinBase wallet you can transfer with no fees to the GDAX exchange)
or Bitfinex, which currently is the largest volume Bitcoin exchange out there.
Be warned though, I suggest you use exchange wallets for short term, many large exchanges have been hacked in the past, the best example would be MT. Gox
If you want to play it safe and have the actual wallet on your computer, just download BitcoinCore on to your favorite/most accessible/secure computer. However, you have to download the Blockchain, which takes a bit, but is worth the time and storage for some.
Happy Bitcoining


text:
Setting up BFGMiner with Devices
I have a Dell Poweredge Server R200 set up with BFGMiner.  Now I know this is old and not very powerful, but I am curious as to how I should use BFGMiner.
When I ran it initially, it was not able to find any devices (unless I am doing something wrong).  I have an Advanced Micro Devices [AMD] nee ATI ES1000 VGA compatible controller but I dont know how to use this or the CPU for BFGMiner.

Hopefully, this following quote from the Github Source will help to shed some light on your trouble to get BFGMiner to use your CPU:

EXECUTIVE SUMMARY ON CPU USAGE:
By default, BFGMiner will NOT mine on CPUs unless it is explicitly compiled with
support and told to do so. CPU mining for bitcoin is generally considered to be
obsolete as it requires considerably more power per hash computed than either
GPU, FPGA or ASIC based mining. If you still wish to mine using CPUs you will
need to build a custom binary with support enabled (refer to the build notes in
README for further information).

The page continues to enumerate flags for the usage of BFGMiner with CPU.

If you wish to keep with the same hardware, I suspect you'll get more money out of vanity-address mining than to mine bitcoins directly. Even then it might not be very efficient.
Vanity-address mining is like the equivalent of having a personalised number plate on your car; it involves hunting the bitcoin address space for a public address that starts with a short string (up to 8/9 characters is reasonable with some effort) someone chose, and with the right algorithm can be done securely so you never know the final private key in use.
It cannot be done with ASICs at present (AFAIK), but can be done using GPUs so the relative value is higher per hash-checked; though it does a quite-different operation so the very-specific ASICs aren't built to find the addresses.
(see https://bitcointalk.org/index.php?topic=84569 and https://vanitypool.appspot.com/ for further info/a running pool of wanted addresses).


text:
BFGMiner for Debian Wheezy
Is it possible to install BFGMiner on Debian Wheezy?
I have been looking for a solution but I can't find one.

What happens when you try?

There is no specific package for download that I can find for debian. They are for Ubuntu

So, you build it from source.  There's a nice README in the source package.  There's even a README.Debian discussing how to make it into your own debian package.

Really? Ill check it out

Download the bfgminer source code, extract the source, change directory into it.
Then:
$ dpkg-buildpackage -uc -us -rfakeroot
And it'll build a package you can install on Debian Wheezy. You will need to install "dpkg-dev" for dpkg-buildpackage and all the build dependencies, which you'll find out by running the dpkb-buildpackage command.

you have to patch it first before building the package;
patch -p1 < debian/patches/bfgminer-bitforce.diff

No, dpkg-buildpackages will install patches in debian/patches by itself.


text:
Need help understanding how to profit from bitcoin trading (like forex?)
I want to understand something very basic. How does trading work between BTC & USD.
Let's say I have 1 BTC at US 100. The naive idea is "buy low" and "sell high". But I don't grasp how that work, ie, how is possible to profit in both directions.
If the value of BTC change this way (value in USD):

110 85 102 40 70 90 115 130 100 200

What I need to do to turn a profit? And if my plan is that I don't lose more than I invest at the start?

Pretty simple. You just make money on the differences when you buy/sell (taking in to account fees).
In your example, you start with 1 BTC purchased at $100 USD.  Assuming no fees, you would:

Sell at $110 (Profit: $10)
Buy at $85
Sell at $102 (Profit: $17, total: $27)
... and  so forth

Now, you could get even more creative, since you can purchase fractions of BTC.  In this case, you could:

Sell at $110 (Profit $10)
Buy 1.294 BTC at $85 each for $109.99
Sell at $102 for $131.98 (Total Profit: $31.98)
...

The key benefit of trading Bitcoin against the US Dollar, using the leverage like with other currency pairs is that it allows traders to increase the size of the position with only a limited amount of investment. Check http://forex-metal.com, they offer bitcoin trading


text:
Can one rig run multiple different graphics cards?
I have some 7950 and some R280, can I connect them both on one rig? Will it work normally? Or does system require all GPUs to be same?

Nope, you're good to go. You don't even have to connect them all through PCI-e. With cgminer, you can set the settings uniquely for each card. You can use any kind of adapter that would normally bottleneck GPU performance.

I'd assume that your weakest link would be the motherboard.

"You can use any kind of adapter that would normally bottleneck GPU performance" .. so using a PCIe x1 to PCIe x16 OR PCI to PCIe adapter would be ok?


text:
What does "buy the dip" mean?
I keep hearing "buy the dip" constantly with Bitcoin people/comments.
I get that it means that you should buy Bitcoin while the price is temporarily low, but what do they mean by it? Do they assume that people have a bunch of money just sitting around waiting to be spent? If they have the ability to buy Bitcoin, and they have money, why would they not have already done so, and thus have no money to spare?
Am I just unique in that I don't have any massive streams of income constantly flowing into my bank account for me to "buy the dip"? For me to afford a single small purchase on Bisq, I'd need about $500, which translates to several full months of me saving all the money I don't absolutely need. To buy a little BTC once. And then my bank account is drained again, and I have to start over saving for months to make another such minor purchase.
What do they mean by "buying the dip"? Do people normally have enormous amounts of money piled up just "waiting for the right time to invest"? Are they deliberately acting arrogantly as to pretend that they are super rich and assume that everyone else also is? Do they genuinely not understand that others aren't as super-rich as they are? I don't understand it.

I get that it means that you should buy Bitcoin while the price is temporarily low, but what do they mean by it? Do they assume that people have a bunch of money just sitting around waiting to be spent?

If you hold a lot of cryptocurrency and have a balanced portfolio, that will mean a lot of low risk holdings. That might not be cash, but it's likely to be things that can easily be exchanged for cash.

If they have the ability to buy Bitcoin, and they have money, why would they not have already done so, and thus have no money to spare?

That would mean that you cannot profit from drops in price. Since bitcoin is a very volatile asset, why would you want to deprive yourself of the ability to profit from its drops in price?
For example, one very simple "buy the dip" trading strategy is to keep a pile of cash equal in size to your pile of bitcoin. This means that you buy bitcoin when it goes down and sell it when it goes up. This allows you to profit from rises and drops in the price of bitcoin even if it returns to a price it previously held. You can't do that if you buy and hold.

Am I just unique in that I don't have any massive streams of income constantly flowing into my bank account for me to "buy the dip"?

You're probably not unique, but you're also not a trader. "Buy the dip" is a trading strategy.
Another "buy the dip" strategy would be to sell stock and buy bitcoin after a 20% drop in the price of bitcoin. This doesn't require you to have huge piles of cash around.

You're spot on!
I don't have enormous gobs of cash sitting around (who does?!) but as I get paid monthly I have some sitting ready for bills or going out next week. Buy the Dip - or more bluntly - Buy the F'ing Dip (BTFD) - is a reminder that:

The dip will be temporary
Don't later regret that you didn't buy
Consider buying a dip IF YOU ARE ABLE TO

Interesting commentary from Dr Adam Back talking with Preston Pysh and PlanB on Preston's podcast recently; accepted experience/wisdom was to ignore dips below 20% - that is a "dip" of 10% wasn't even worth the definition of "dip". Larger dips of 20%+ are therefor worth buying if you're able.
For me, I dollar cost average with a daily buy so I don't really watch the price - some days I get more sats, some days I get less sats, but at the end of every day I have more sats than yesterday.
Over the long term bitcoin will rise in value, and therefore I've protected my savings (future purchasing power). It's that simple. I'm not a trader. I don't have great gobs of cash sitting around. Work in a job and earn living, pay my bills, and save in bitcoin.
Do what you're able. :-)
PS - During the 2017 bull market there were about half a dozen dips of 30%; this dip is the first half decent one so far. aka: this is normal for bitcoin.


text:
Who provides the computers and infrastructure for bitcoin transactions to happen?
I am new to bitcoin. I have some fundamental questions.

If bitcoin does not have any centralized entity controlling it, who provides the infrastructure for the trades to happen? Does this has something to do with mining?
Another issue comes to mind is, in case if full anonymity of bitcoin transactions, how can someone create trust between merchant and customer. For example, if I order something online using BTC and don't receive the goods, how can I make sure I will get justice in terms of refund etc.

Hey, welcome to Bitcoin.SE. SE works much better if there is only one question or very closely related questions in one post. Please check out [ask], if you haven't seen it yet. Also, please try to research your questions first. Part of your question has answers already: See What exactly is mining?, Who controls the Bitcoin software?.

Two different questions in the same post.

If bitcoin does not have any centralized entity controlling it, who provides the infrastructure for the trades to happen? Does this has something to do with mining?

Whoever wants to do something provides the infrastructure to do it. If you want to perform a transaction, you have to provide enough infrastructure to perform a transaction or use someone else's infrastructure. Miners provide the infrastructure to confirm transactions in exchange for the block rewards and transaction fees.

Another issue comes to mind is, in case if full anonymity of bitcoin transactions, how can someone create trust between merchant and customer. For example, if I order something online using BTC and don't receive the goods, how can I make sure I will get justice in terms of refund etc.

The same way you do with other currencies -- you pay through a provider that provides this service or you only make payments to people you trust. There are any number of Bitcoin escrow services.

1.) Yes, when mining each block validates all of the transactions that have occurred since the last block.  This is also where transaction fees go, if you choose to include one the device that mines the next block will earn it in addition to the set reward for that block.
2.) There is not full anonymity between Bitcoin transactions, there is pseudo-anonymity which means that transactions can really be traced and a person can be tied to coins that they own if/when they are spent because the address that contains the coins becomes an input for the next transaction.  The anonymity is pseudo because one person can control any number of addresses which only makes analysis harder but not impossible.  When it comes to trusting a merchant I would say that you should use the same rules as you would when you enter your credit card information into a website.  Ensure that sensitive personal information (shipping addresses, phone numbers, etc) is encrypted using SSL, that there is a valid contact for customer support etc, perhaps perform a whois on the site and see if the owner has public contact information.  Most of all look for reviews and references of other customers experiences.  This may be harder to do with some Bitcoin start ups but the Bitcoin talk forums often has information on businesses that are involved in the community.
Due diligence is the key to avoiding scams in the Bitcoin world.

Actually, In case of credit card, I can dispute the transaction and then the merchant has to prove the legitimacy of the transactions. Also, there is a bank/credit card company involved to get through the process etc. What is the process in case of bitcoin in this kind of scenarios.

It would be up to the merchant to provide a refund or make the transaction right.  Customers could also protect themselves using  a third party escrow to ensure both parties are satisfied with the transaction before funds are finalized.

authors: Андрей Казаков

authors: МИХАИЛ ЕРШОВ


text:
Bitcoin transaction with 0.0001 BTC fee not getting confirmed?
I sent the following transaction a few hours ago with Bitcoin-QT:
https://blockchain.info/tx/b5682b48484a8752be62c6b4036eaf8a8f005d9ea75cbff434476b7506a9e3a2
And the transaction still has not been confirmed. I attached 0.0001 BTC transaction fee.
Did I lose the money? Can I do something to speed up the confirmation of the transaction?

looks to me like it says your transaction will take up to 26 hours and that your transaction fee was low

@MarkS. Is it possible to double spend it with an added fee? I'm using bitcoin-qt on mac.

I don't think any standard wallet will let you double-spend... you would have to hack the transaction yourself.  And even then it probably wouldn't work unless you mined the block yourself.

There is a time limit for transmission by most clients. I think Bitcoin-qt used 3 days. After that you can spend it again