15

Someone wrote a Bitcoin protocol decoder for Wireshark, several years ago. I assume it was included in the Wireshark distribution. Wireshark simply knows about the Bitcoin protocol. There is no magic involved.


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 ...


8

Original meaning of nSequence in transactions nSequence is a 4 byte input level feature. The original meaning of nSequence was to allow modification of transactions in the mempool. So, if the nSequence value of the input was less than 0xFFFFFFFF (4294967295 in decimal), it indicated a transaction that was not yet finalized. Such a transaction would be held ...


8

The Blockchain is the only truth At the time I wrote this, that transaction has 204 confirmations. That means it was absolutely definitely received. If the address is correct and the recipient says they didn't "receive" it, they are wrong. Either their wallet isn't properly synchronised or they are mistaken (or lying to you) Note that Bitcoin doesn't ...


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

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

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 ...


6

When you sign the transaction with your private key, you include the hash of the entire transaction data as a message. This means the signature which is generated is specific to that transaction itself and any modification to the transaction will render the signature invalid. In this case, the user who has signed the transaction has already specified the ...


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

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

HD vs non-deterministic: "HD" means "hierarchical deterministic". "deterministic" means: all your private keys are generated from a seed, "knowing your seed = knowing all your private keys", so that frequent backup is no longer needed. "hierarchical" means: you can manage multiple coins/accounts/address types with only one seed. Watch-only wallets are ...


4

There are currently three different ways to do this: raw transactions, PSBT in 0.17, and PSBT in 0.18. I recommend that you use PSBT in 0.18 as it is the least hassle, but I will describe all three here for you. Traditionally, you would do this with createrawtransaction, fundrawtransaction, and signrawtransactionwithkey/signrawtransactionwithwallet. One ...


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. ...


4

The main difference is that Bitcoin in lightning network channels are in 2of2 multisig wallets. You own a key and your channel peer owns the second key. Your funds are "safe" because you have pre-signed transactions that spend from that multisig wallet (similar to an offline signing of a transaction). As soon as you keep those pre-signed transactions, your ...


4

it means that proportion of fresh node should be bigger than proportion of legacy node. The requirement for segwit's activation was that the majority of the hashrate signaled readiness for activation. Although this process was frequently misconstrued as a "vote of miners", the activation proposal actually requests that miners judge whether the majority of ...


4

Then the blochain of the "hacker" will have 1 block more than the others, thus it should be, at least for a few minutes, the "valid" blockchain This is incorrect. A block that contains an invalid transaction is invalid, period. The network's rule is that the longest(*) valid chain is the one to be treated as correct. A chain with any invalid blocks in it ...


4

A hardware wallet only has responsibility for handling private keys. This includes generating addresses (when receiving), and signing transactions (when sending). It needs some sort of communication with the outside world to do this. There's multiple hardware wallets on the market, and they don't all operate the same way. However, the principles are the same....


4

At a protocol level, they are all compatible. Transactions can spend any of them, and send to any of them. Wallet software may of course have restrictions, but these are usually not about combinations. E.g. some wallets may be unable to generate a p2sh-segwit address to receive on, or be unable to send to bech32. However, I have not heard about software ...


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