SegWit cannot, and was never designed to "resolve network congestion". It:
fixes the third-party malleability issue that Bitcoin has had since its creation, vastly simplifying many multi-transaction smart contract constructions (like Lightning).
fixes the O(N2) signature hashing problem.
adds amount commitments to signature hashing, simplifying design of ...
SegWit2x is a combination of both SegWit and a 2MB hardfork (to activate three months after SegWit).
SegWit2x uses a different 'bit' for signaling (bit 4 instead of bit 1) than SegWit.
SegWit (BIP141) is not activated at the moment because it requires 95% of the mining hashrate, and not enough miners support SegWit at the moment, because some miners want ...
Yes and no. It depends on how you frame the question.
It is a block size increase, because you can fit a larger number of
useful transactions into a block.
If you want to make a useful Bitcoin transaction, it has to be signed so that nobody else can change it. If you can find a way to make the block size limit not count the signature, then you can fit more ...
It's not a silver bullet solution, but it's a really good start.
As Gavin Andresen has said, Segregated Witness is a poor name. The 'segregated' part of the name is there to denote that there is separation being done. The 'witness' portion of the name comes from the fact that digital signatures are often time called witnesses.
Segregated witness splits ...
How do I generate a SegWit address using Bitcoin Core CLI?
You can use addwitnessaddress addr, where addr is an existing P2PKH or P2SH address of yours. It will construct a P2SH-P2WPKH or P2SH-P2WSH address with the same key/script, if known to be valid.
Note that this command is not available until SegWit is active on the network, as before that time, ...
Why a witness commitment is necessary at all: Enabling DoS prevention for validating nodes
Block validation is expensive. It requires hashing all data in a block, building Merkle trees, looking up all inputs from the UTXO database, running script and ECDSA validation, do various consistency checks, and updating the UTXO database. If random peers could make ...
SegWit does not reduce the transaction size, if you're referring to the raw byte length of transactions. Instead it introduces block weight as a new metric that does not directly correspond to the raw byte length of transactions, but treats witness data as having less weight than other parts of the transaction.
The limit for Bitcoin blocks has been ...
You're confusing transactions (the abstract object) and their serialization (the bytes on the wire in the P2P protocol or on disk).
Sure, SegWit introduces an extension to the P2P protocol (BIP144), which relays witnesses along with transactions, and old clients wouldn't understand such messages.
But old clients don't see them. Witnesses are only included ...
The name itself is a good hint as to what it actually does.
What we have today is a "witness" (i.e signature scripts) included in every Bitcoin transaction in non-segwit compliant transactions. This allows every full node within the Bitcoin network to verify the integrity of any transactions.
By removing the signatures in a Bitcoin transaction, you lose ...
What does the UASF proposal entail?
The UASF proposal is an extension of BIP9 that allows soft-forks to specify a mandatory activation time. If miners have not started signaling support by this time, they must start to signal. Any blocks not signaling support for the soft-fork after this time are rejected.
BIP148 is an instance of the UASF proposal that ...
Very interesting question, let's see what the smallest transaction we can build is. For it to be minimal it has to be a single input and a single output. The non-segwit part would look something like this:
4 bytes version
1 byte input count
36 bytes outpoint
1 byte scriptSigLen (0x00)
0 bytes scriptSig
4 bytes sequence
1 byte output count
8 bytes ...
Say, my raw transaction is 500 bytes,100 bytes of which are witness data. Thus, 400 bytes are now competing for the place in 1 Mb block.
That's not correct.
SegWit replaces the concept of size and maximum block size with weight. The weight of a transaction is defined as 3 times the stripped_size in bytes (excluding the witness) plus the total_size in bytes ...
Best estimates on effective blocksize with SegWit are 1.6-2.0 MB.
Current transactions/second possible are around 3 tx/s. Given that the effective increase is 1.6 - 2.0x, the transactions/second are also the same multiple giving us somewhere around 5-6 tx/s.
The second question is harder to answer. There's a reason I wrote "effective blocksize" since ...
Is it acceptable to mix P2PKH and P2WPKH inputs in the same transaction as described above?
Yes, absolutely. In the same way that you can mix multisig and P2SH and P2PK inputs in the same transaction.
When would I encounter a situation where "all txins in a transaction are not associated with any witness data"
When you're not spending any SegWit outputs....
By reading this answer, I understand that in m-of-n multisig addresses, m and n are limited by the maximum size allowed by the P2SH redeemScript (i.e. 520 bytes).
That's correct. Even though the OP_CHECKMULTISIG script opcode supports more keys, more than 15 public keys simply don't fit in a P2SH redeemscript, so that becomes the limiting factor.
A sidechain has its own blockchain which is coupled to the Bitcoin blockchain via a two-way peg. This allows tokens on the Bitcoin blockchain to be frozen in order to make new tokens available on the sidechain. In turn tokens on the sidechain can be either destroyed or frozen to move money back to the Bitcoin blockchain.
Lightning Network is not a sidechain....
Is it safe to receive funds at this 1FJJd... address?
Kind of. Your wallet knows the private key that corresponds to that address as it is the same private key for the bech32 address. However it does not necessarily know that it should be looking for coins sent to this address, so any transactions that send coins to that address may not appear in your ...
Let's compare a 2 input and 2 output transaction for variants of pay-to-pubkeyhash. (Full data below.)
P2PKH has no witness, so raw size is equal to stripped size is equal to virtual size. A P2PKH transaction with two inputs and two outputs has 374 bytes (= 374 vBytes).
P2SH-P2WPKH (wrapped segwit) locks funds to a P2SH output in which it redirects to a ...
That depends on what those inputs and outputs look like.
The formula, as specified in BIP141, is:
Call base_size the number of bytes needed to serialize the transaction in legacy format (which does not include the witnesses).
Call total_size the number of bytes needed to serialize the transaction including witnesses.
The weight of the transaction equals 3*...
Bech32 is an address format that was only recently proposed. While its design had input from multiple wallet authors, it is way too early to say anything about adoption.
It is important to realize that there is no hurry about this. Every usable address type is available through embedding in P2SH, which is compatible with every wallet created the past few ...
Why does this document seem to imply that the birthday attack only works for multisig P2SH and then only for one of the signers?
The birthday attack (to the best of my knowledge) requires that the P2SH address is constructed from a script which involves both a key of the victim and the attacker. That is typically only the case for multisig, but is not ...
There's 2 versions of ASICBOOST:
Overt where miners use bits in the version number as extra nonce space
Covert where miners "mine" merkle trees with 4 bytes collisions
The overt version is very easily detectable, whereas the covert one isn't.
To mine these merkle trees for the overt version, miners need to shuffle the transactions in the block.
This structure contains data required to check transaction validity
but not required to determine transaction effects. In particular,
scripts and signatures are moved into this new structure.
The witness is a serialization of all witness data of the transaction.
Each txin is associated with a witness field. A witness field starts
with a var_int to indicate ...
Disclaimer: I'm a Blockstream co-founder and the primary author of the SegWit proposal.
I believe SegWit benefits everyone in the Bitcoin ecosystem. It solves several long-standing problems that hurt future evolution and scalability:
Transaction malleability complicates multi-transaction contracts
Lack of script versions makes introduction of new opcodes ...
The right way to look at it is that every transaction input has a witness. For legacy outputs being spent, that witness is just empty.
So yes, mixed SegWit and legacy inputs are possible. SegWit transaction serialization will be used, and the witnesses for all legacy inputs will be empty.
That's not accurate. The witness is stored in the blockchain.
In the segwit format, the signature is part of the witness, the witness is part of the transaction and the transaction is written to the block in full. Nodes that understand segwit will download and store the complete transaction including the signature.
However, segwit is constructed in a ...
Transfer from Legacy ⟶ SegWit: pay full fee (doesn't benefit from SegWit discount)
Transfer from SegWit ⟶ Legacy or SegWit: discounted.
Note: SegWit addresses can be Bech32 bc1... or they can be nested in a legacy P2SH 3... address which are backwards-compatible (although less efficient). Many exchanges, wallets support the legacy "nested" form only.
The HRP is part of the bech32 encoded string, and in the bech32 decoding API, it is returned along with the payload by the decoder, after checking the checksum.
We still want to compare it with the expected HRP in BIP173, which encodes the chain the software is operating on.
Otherwise you could have a testnet node that accepts mainnet BIP173 addresses or ...