In this answer, I will go through the steps necessary to redeem the second output of the transaction listed above. The answer will be limited to redeeming an output of the particular type present in this transaction (an output which requires providing a new transaction signed with a private key whose corresponding public key hashes to the hash in the script ...
Note: I went out and learned about how the OP_RETURN opcode works at the byte level in a bitcoin transaction. I’m writing it here so that others can learn quickly. First, a brief history of why we’re even talking about OP_RETURN.
Back in 2013 different players in the bitcoin ecosystem were trying to include bits of information into transactions so that they ...
I know this question is old, but I stumbled upon it looking how to teach myself how multisig addresses work, and I imagine others will to. So I’m going to try to explain the typical flow for creating, adding bitcoins to, and eventually spending a multisig address. This explanation is aimed at beginners, so please excuse my lack of brevity. First off, some ...
An unspent output is simply an output of a transaction which isn't yet an input of another transaction.
To take the example from ripper234's answer (in which generated coins are immediately spendable, and we don't have to wait 100 blocks for them to mature), where:
The first block contained 50 mined BTC in address A (A = 50)
The second block contained 50 ...
First of all two matching scripts are used in two different transactions, one that transfers funds to an address (Transaction A) and one that spends those funds (Transaction B). The scriptPubKey is created by the user that creates Transaction A. It basically adds a claiming condition to the output that is being created. A user may only claim and thus spend ...
I'll try answering this again in a different way,
using small numbers to keep it readable.
convert the private key to binary representation, so decimal number 105, which is 0x69 in hex, becomes 01101001.
calculate this list of points, by repeatedly doubling the Generator point G:
2*G = G+G
4*G = 2*G + 2*G
8*G = 4*G + 4*G
16*G = 8*G + 8*G
32*G = 16*G + ...
The details are very complex, but the core concept is fairly simple. Ripple solves the double-spend problem by consensus.
The analogy I use is an "agreement room". To walk into the room, you have to agree with everyone who is already in there. If you want to disagree, you have to leave and form your own room. Everyone who is honest wants to get into the ...
The term "coinbase" is used to mean many different things. But the two you're probably asking about are:
The "coinbase transaction" is the transaction inside a block that pays the miner his block reward.
Inside the coinbase transaction is a field that is called the "coinbase". It's the generation transaction's equivalent of a scriptsig. Since it doesn't ...
The Bitcoin P2P network
The Bitcoin P2P network is a randomly-wired gossip network. This means that all nodes make arbitrary connections to other peers (using various ways to discover new addresses) using a custom TCP protocol, usually using port 8333. Typical nodes create 8 outgoing connections, and if publicly reachable, accept up to a few 100 incoming ...
Bitcoin transactions have a transaction id (txid) formed as a hash over the data involved in the transaction. That suggests that it is a unique identifier for a transaction.
However, the tx-id of a transaction is only unique once the exact data in the transaction has been finalized by being incorporated into the blockchain (and confirmed). Until then, there ...
Bitcoin amounts in the protocol and software are expressed as an integer number of "satoshis". 1 BTC is defined as 10^8 satoshis. So a block reward that is internally represented as 5*10^9 satoshis is displayed in the GUI as 50 BTC.
Splitting bitcoins to even smaller fractions will require a change in the protocol and software, and may be done when their ...
Note that the accepted answer is outdated.
Currently, sequence numbers are mainly used for signaling RBF - replace-by-fee - that allows you to resend a transaction with a higher fee.
See https://bitcoincore.org/en/faq/optin_rbf/ , https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki
While the other answers are slightly true, there's another reason. Addresses which have been spent are inherently less secure than unspent addresses. This is because, when spending on an address, you reveal the public key to the address. This means that in order to steal those funds, you only need to find the private key, whereas normally you'd need to break ...
The information in David's answer is correct, but it may not answer the actual question -- it's unclear whether the question is about change in general, or specifically sending change to a new address.
If the latter, nothing needs to be added. If, however, the question was about the practice of change in general, then yes, it is necessary.
The reason for ...
The bitcoin wiki OP_CHECKSIG page describes the behaviour of SIGHASH_NONE like this:
The output of txCopy is set to a vector of zero size.
All other inputs aside from the current input in txCopy have their
nSequence index set to zero
Think of this as "sign none of the outputs-- I don't care where the
The contracts page also ...
Bitcoin uses double hashing almost everywhere it hashes in one of two variants:
RIPEMD160(SHA256(x)) called Hash160 which produces a 160 bit output
hashing the public key to generate part of a Bitcoin addresses
SHA256(SHA256(x)) called Hash256 which produces a 256 bit output
generating the checksum in a Bitcoin address
hashing the block in a merkle tree
When developing Bitcoin, Satoshi had already come with the idea that no more than 21 million of them will ever be made. However, there was an unsolved issue: how to accomodate all bitcoins in case it was actually used as a worldwide currency? Comparing to the current (2008?) world's M1 supply, it was determined that 8 decimal places was enough to cover the ...
At the protocol level, there is no such thing as "balance of an address". There are individual unspent outputs (like coins in a wallet), which must be individually spent. You can't partially spend an output, but you can split/combine it.
So for example, you have a 70 BTC output assigned to an address, and a 80 BTC output assigned to the same address. Some ...
I am just guessing here given the little I know about bitcoin and distributed databases.
This comes down to the how CAP theorem applies to the bitcoin blockchain DB.
CAP theorem states that it is impossible for a distributed computer system to simultaneously provide all three of the following guarantees:
Consistency (all nodes see the same data at the ...
The target section of the block header is called nBits in the code. nBits is a 32-bit compact encoding of a 256-bit target threshold. It works like scientific notation, except that it uses base-256 instead of base-10. For example, if nBits is equal to 0x181b8330, you would calculate it like this:
Or, more simply, you'd use the same shorthand you use with ...
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.
It means "Bitcoins that were not spent".
Imagine the early days, when the blockchain was of length 3 (imaginary chain of events):
The first block contained 50 mined BTC in address A
The second block contained 50 mined BTC in address A, a TX sending 20 BTC to address B, and putting the change in address C
The third block contained 50 mined BTC in address A, ...
From Zooko's answer provided in Crypto StackExchange:
SHA-256(SHA-256(x)) was proposed by Ferguson and Schneier in their
excellent book "Practical Cryptography" (later updated by Ferguson,
Schneier, and Kohno and renamed "Cryptography Engineering") as a way
to make SHA-256 invulnerable to "length-extension" attack. They called
From what I gather you sign both the input and the output of the transaction, meaning that nobody can alter the content of the transaction without invalidating your signature. I also had some problems with this part of the algorithm, and even asked a similar question earlier, but this one deals with more of the low-level bit operations rather than the high-...
This thread explains it.
It's a method that allows replacing an already transmitted transaction by transmitting another transaction with a higher fee. This only works on transactions before they are signed by miners (0-confirmations).
Here's a good interview by Gregory Maxwell himself who's a Bitcoin developer:
Oh there is a “problem” in the Bitcoin protocol, known since at least
2011 (see the link I gave). But for normal applications, not involving
unconfirmed transactions, it shouldn’t cause any severe problems
because wallets can handle it locally.
This has to do with ...
However, what happens when my generated private key matches a private key that is already used?
Then you got lucky, and can spend someone else's coins.
Does the protocol reject private keys if they are already used?
No, how should it? Keys can be used more than once in normal operation.
Fortunately, it is extremely unlikely that this ever happens. See ...
What malleability means is that you can't store the transaction ID that bitcoind returns from its sendtoaddress API call and expect that number to mean anything at all later.
Instead, if you want to keep track of a high volume of outgoing transactions, you have to wait for the transactions to be fully confirmed and immune to blockchain reorganizations, and ...