9

With Bitcoin Core you'll run a full node. So, for every transaction someone does to your business, your Bitcoin Core wallet need to be synchronized with the complete blockchain.


9

I read briefly in a paper that there is some sort of transaction queue that the node keeps for each neighbor and that they will only select a random (?) amount of those transactions and send in an INV message to those nodes. Note that this is specific to Bitcoin Core. Other full node software may not exhibit this behavior. When Bitcoin Core receives a ...


8

No. Bitcoin has no concept of countries or other societal constructions such as laws.


8

This sounds like a scam, or at least, an attempt to compromise your computer with malware. Sending someone a Bitcoin transaction does NOT involve sending someone an executable file. It involves using the bitcoin network to send a bitcoin transaction that moves some amount of bitcoin to addresses owned by the transaction's participants. You can generate ...


7

My search on this website did not reveal a single answer that comprehensively explores nSequence and how it has evolved since inception. They either address a particular query or are dated like this. If you can find a better/older answer, mark this question as duplicate. Original meaning of nSequence in transactions nSequence is a 4 byte input level ...


6

Varying the signature per input helps prevents some attacks during multi-party transaction construction. Consider a coinjoin involving Alice and Bob. Alice selects one of her UTXOs for the coinjoin. Bob chooses a UTXO for his input, but he actually selects ones of Alice's other UTXOs that reuse the same address as the one she selected. Alice does not ...


6

Can I send almost 1MB transaction? To be able to send a transaction that a miner will accept, that transaction has to be a standard transaction. As defined in policy.h /** The maximum weight for transactions we're willing to relay/mine */ static const unsigned int MAX_STANDARD_TX_WEIGHT = 400000; For non-Segwit transactions, the limit is 400,000 KB / 4 = ...


6

Is there a specific attack or bug which asymmetric cryptography prevents during bitcoin transactions? asymmetric cryptography is not really something that was added on top of Bitcoin in order to prevent some specific attack or fix some specific bug. asymmetric cryptography is one of two fundamental foundation stones, one of the two primary building blocks ...


6

Occasionally, minor alternate chains emerge if multiple blocks are found for a given blockheight. Usually, these alternate chains only last for a single blocked, and are quickly dropped once another block has been found, allowing one chain to become longer (and thus have more work). More rarely, these chains might last for a couple of blocks. Block 525890 ...


6

The hourly average fee when this question was posted was between 9 and 10 Satoshi per Byte (sat/B). The latest TX's that I just randomly checked all had 10.03 sat/B fee which is higher than the 4.5 sat/B that you sent. Transactions are at a hourly peak right now. Wait it out and it'll probably go through in the next couple of hours as the mempool empties. ...


6

In this point, if Bob make a fraud transaction with Segwit, legacy node will accept, but it is not accepted in terms of fresh node. so, some group(legacy nodes) accept, other some groups(fresh nodes) doesn't accept. it means that proportion of fresh node should be bigger than proportion of legacy node. I think that this is really critical issue but ...


5

It doesn't. From the point of view of the blockchain there are just 2 transactions: one going into an exchange address the other is going out of an exchange address. For example: You sent 0.1 btc to an exchange [recorded on blockchain] Some other people send other amounts to that exchange (exchange controls all these addresses) [recorded on blockchain] ...


5

Any script can be used in P2SH/P2WSH technique. Using arbitrary scripts in transaction outputs cause grows of UTXO database and other problems.


5

Without asymetric cryptography, there wouldn't be information asymmetry: in other words, everyone knows exactly as much as everyone else. If everyone knows equally much, there is no way to distinguish a legitimate sender from a malicious one. More specifically, if a symmetric construction like an HMAC was used to authenticate a transaction, miners would ...


5

Your transaction paid a fee of 1674 satoshis for 372 bytes, or a fee rate of 4.5 satoshis per byte, which was a reasonable estimate in the past hour (via https://mempool.space/tv): There was just a slow block with #600,283 taking 37 minutes to be found (via https://blockchair.com) and it looks like your transaction would have been exactly in that little ...


5

Yes, miners can censor transactions. A mining pool (or solo miner) can choose to not add a transaction to any blocks that they create. And, of course, this can be done dynamically so that transactions that match whatever arbitrary rules they want can be disallowed. However this only effects one mining pool or miner. Other miners will not necessarily follow ...


4

you can find explanation here: https://bitcointalk.org/index.php?topic=5095376.msg49150302#msg49150302 the issue was actually with OP_RETURN. What OP_RETURN used to do is it would skip to the end of the script so whatever was on the stack was interpreted for the final script result. So what you could do was create a scriptSig that was just OP_TRUE ...


4

Will both Bob's transactions be confirmed in the same block? This cannot be guaranteed. They might or might not. consider the case when Bob sends all 10 bitcoins to Alice in one transaction and simultaneously issues another transaction to send Uncle Tom the same 10 bitcoins. Bob's wallet will not allow him to double-spend. If Bob circumvents this, one ...


4

Yes, a channel opening involves creating and signing 3 transactions, and broadcasting just one. The transaction to be broadcast funds the channel, and spends to a multisig output. It is signed by whomever chooses to fund the channel. When this funding tx receives sufficient confirmation, the channel is considered open. This multisig output is spent by two ...


4

The network used today isn't actually the same as the original design, which did not have an inventory system at all, every transaction and every block was sent to every peer indiscriminately. Compact Blocks was also added to remove redundancy in block transmission and reduce latency, as blocks predominantly contain transactions which have already been ...


4

Why is there a limit? Why don't we change it? No matter the number of transactions broadcast to the network, there is an implicit maximum number of transactions that can be included in a block (see @JamesC's answer), and the number of blocks found is regulated by the network's difficulty adjustment algorithm, aiming for an average of one block every ten ...


4

No, bitcoin transactions that stop being valid after a certain point in time are not possible


4

Comments that you add to transactions are for your wallet only. No one else will see them as transactions do not have anywhere to have comments. Comments on public blockchain explorers (such as tags on blockchain.info) will only appear on those websites as they are comments specific to those websites. They are not part of the transaction itself.


4

No, the number that can be represented by the varint has no effect on the maximum number of inputs. That number is far too large. Rather the maximum number of inputs is constrained by the block size. If it really matters to you what the maximum number that a varint can represent is, it's just the maximum value for a 64-bit integer. That's 0xffffffffffffffff....


4

A transaction is confirmed when it is included in a block, so you will need to watch for a message that alerts your node (or whatever software you are using to watch the P2P gossip traffic) to a new block, that includes the transaction in question. It doesn't matter if a node run by a miner relays your transaction to other nodes on the network, it only ...


4

I also believe I read that the signature part can account for 65% of the block size. This is not entirely correct. The typical size of a block depends on the make-up of transactions in that block. The size of signatures to overall block size will depend on the number of inputs in a transaction. More the number of inputs in a transaction, higher the ...


4

Note that Bitcoin transactions don't actually contain the txid or hash within them. This is only part of the decoding output from Bitcoin Core. The hash is there because of segwit. Segwit specifies that witness data for a segwit input (i.e. signatures, scripts) are not part of the txid. Those are in a separate area in the transaction. You can see this ...


4

Blockchain Explorer says received but it's not received yet! That's not how Bitcoin works. All computer-based wallets, including your friend's, have a copy of the blockchain (or have indirect access to a copy). If the blockchain includes your transaction, then the money has been received. All copies of the blockchain are eventually identical, only the last ...


4

Once spent, the wallet removes the UTXO from its cache of unspent transactions. The transaction is not removed from the general database (the blockchain or block index). Full nodes running with txindex=1 keep every transaction forever. Some wallets though optimize the database to recover disk space - but this is a wallet-specific optimization and not part of ...


4

The method described in the post has nothing to to with OP_RETURN, but is concerned with the SIGOP limits in a block. Each block has a limit on the number of SIGOPs that can be present in transactions in that block. Signature validation is a CPU intensive operation, and the limit exists to ensure that no block gets too big to validate on regular hardware. ...


Only top voted, non community-wiki answers of a minimum length are eligible