[bitcoin-dev] Why SegWit Anyway?

[Praveen Baratam via bitcoin-dev]

Bitcoin Noob here. Please forgive my ignorance.

From what I understand, in SegWit, the transaction needs to be serialized
into a data structure that is different from the current one where
signatures are separated from the rest of the transaction data.

Why change the format at all? Why cant we just compute the Transaction ID
the same way the hash for signing the transaction is computed?

[Ariel Lorenzo-Luaces via bitcoin-dev]

Hello Praveen

You're absolutely right. We could refer to transactions by the hash that gets signed.

However the way that bitcoin transactions reference each other has already been established to be hash of transaction+signature. Changing this would require a hard fork.

Segwit is the realization that this could be done as a soft fork if we simply extract the signature outside of what the old client considers a transaction. And into a new transaction format where we do exactly what you're describing.

In my opinion the way it originally worked with the sig inside the transaction was simply an oversight by satoshi. No different than a bug.

Cheers
Ariel Lorenzo-Luaces

Post by Praveen Baratam via bitcoin-dev
Bitcoin Noob here. Please forgive my ignorance.
From what I understand, in SegWit, the transaction needs to be
serialized
into a data structure that is different from the current one where
signatures are separated from the rest of the transaction data.
Why change the format at all? Why cant we just compute the Transaction ID
the same way the hash for signing the transaction is computed?
--
Dr. Praveen Baratam
about.me <http://about.me/praveen.baratam>
------------------------------------------------------------------------
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Johnson Lau via bitcoin-dev]

We can’t “just compute the Transaction ID the same way the hash for signing the transaction is computed” because with different SIGHASH flags, there are 6 (actually 256) ways to hash a transaction.

Also, changing the definition of TxID is a hardfork change, i.e. everyone are required to upgrade or a chain split will happen.

It is possible to use “normalised TxID” (BIP140) to fix malleability issue. As a softfork, BIP140 doesn’t change the definition of TxID. Instead, the normalised txid (i.e. txid with scriptSig removed) is used when making signature. Comparing with segwit (BIP141), BIP140 does not have the side-effect of block size increase, and doesn’t provide any incentive to control the size of UTXO set. Also, BIP140 makes the UTXO set permanently bigger, as the database needs to store both txid and normalised txid

Post by Praveen Baratam via bitcoin-dev
Bitcoin Noob here. Please forgive my ignorance.
From what I understand, in SegWit, the transaction needs to be serialized into a data structure that is different from the current one where signatures are separated from the rest of the transaction data.
Why change the format at all? Why cant we just compute the Transaction ID the same way the hash for signing the transaction is computed?
--
Dr. Praveen Baratam
about.me <http://about.me/praveen.baratam>_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Johnson Lau via bitcoin-dev]

Not really. BIP140 might be easier to implement, but in longterm the UTXO overhead is significant and unnecessary. There are also other benefits of segwit written in BIP141. Some of those are applicable even if you are making a new coin.

BIP 140 looks like it solves Tx Malleability with least impact on current practices. It is still a soft fork though.
Finally, if we were to create an alternative cyptocurrency similar to Bitcoin, a Normalized Tx ID approach would be a better choice if I get it right!
ᐧ
We can’t “just compute the Transaction ID the same way the hash for signing the transaction is computed” because with different SIGHASH flags, there are 6 (actually 256) ways to hash a transaction.
Also, changing the definition of TxID is a hardfork change, i.e. everyone are required to upgrade or a chain split will happen.
It is possible to use “normalised TxID” (BIP140) to fix malleability issue. As a softfork, BIP140 doesn’t change the definition of TxID. Instead, the normalised txid (i.e. txid with scriptSig removed) is used when making signature. Comparing with segwit (BIP141), BIP140 does not have the side-effect of block size increase, and doesn’t provide any incentive to control the size of UTXO set. Also, BIP140 makes the UTXO set permanently bigger, as the database needs to store both txid and normalised txid

Post by Praveen Baratam via bitcoin-dev
Bitcoin Noob here. Please forgive my ignorance.
From what I understand, in SegWit, the transaction needs to be serialized into a data structure that is different from the current one where signatures are separated from the rest of the transaction data.
Why change the format at all? Why cant we just compute the Transaction ID the same way the hash for signing the transaction is computed?
--
Dr. Praveen Baratam
about.me <http://about.me/praveen.baratam>_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>

--
Dr. Praveen Baratam
about.me <http://about.me/praveen.baratam>

[Dan Bryant via bitcoin-dev]

Is there any incentive for miners to pick segwit transactions over
non-segwit transaction. Do they require less, equal, or more compute to
process?

On Nov 20, 2017 11:46 AM, "Johnson Lau via bitcoin-dev" <
bitcoin-***@lists.linuxfoundation.org> wrote:

We can’t “just compute the Transaction ID the same way the hash for signing
the transaction is computed” because with different SIGHASH flags, there
are 6 (actually 256) ways to hash a transaction.

Also, changing the definition of TxID is a hardfork change, i.e. everyone
are required to upgrade or a chain split will happen.

It is possible to use “normalised TxID” (BIP140) to fix malleability issue.
As a softfork, BIP140 doesn’t change the definition of TxID. Instead, the
normalised txid (i.e. txid with scriptSig removed) is used when making
signature. Comparing with segwit (BIP141), BIP140 does not have the
side-effect of block size increase, and doesn’t provide any incentive to
control the size of UTXO set. Also, BIP140 makes the UTXO set permanently
bigger, as the database needs to store both txid and normalised txid

On 21 Nov 2017, at 1:24 AM, Praveen Baratam via bitcoin-dev <
bitcoin-***@lists.linuxfoundation.org> wrote:

Bitcoin Noob here. Please forgive my ignorance.

From what I understand, in SegWit, the transaction needs to be serialized
into a data structure that is different from the current one where
signatures are separated from the rest of the transaction data.

Why change the format at all? Why cant we just compute the Transaction ID
the same way the hash for signing the transaction is computed?

[Steve Shadders via bitcoin-dev]

There is incentive because of artificially distorted block weight rules. It
is favourable for a miner to choose a segwit tx over a non segwit tx as
they can fit more of them into a block and earn more fees.

On Nov 21, 2017 11:06 PM, "Dan Bryant via bitcoin-dev" <

Post by Dan Bryant via bitcoin-dev
Is there any incentive for miners to pick segwit transactions over
non-segwit transaction. Do they require less, equal, or more compute to
process?
On Nov 20, 2017 11:46 AM, "Johnson Lau via bitcoin-dev" <
We can’t “just compute the Transaction ID the same way the hash for
signing the transaction is computed” because with different SIGHASH flags,
there are 6 (actually 256) ways to hash a transaction.
Also, changing the definition of TxID is a hardfork change, i.e. everyone
are required to upgrade or a chain split will happen.
It is possible to use “normalised TxID” (BIP140) to fix malleability
issue. As a softfork, BIP140 doesn’t change the definition of TxID.
Instead, the normalised txid (i.e. txid with scriptSig removed) is used
when making signature. Comparing with segwit (BIP141), BIP140 does not have
the side-effect of block size increase, and doesn’t provide any incentive
to control the size of UTXO set. Also, BIP140 makes the UTXO set
permanently bigger, as the database needs to store both txid and normalised
txid
On 21 Nov 2017, at 1:24 AM, Praveen Baratam via bitcoin-dev <
Bitcoin Noob here. Please forgive my ignorance.
From what I understand, in SegWit, the transaction needs to be serialized
into a data structure that is different from the current one where
signatures are separated from the rest of the transaction data.
Why change the format at all? Why cant we just compute the Transaction ID
the same way the hash for signing the transaction is computed?
--
Dr. Praveen Baratam
about.me <http://about.me/praveen.baratam>
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Adán Sánchez de Pedro Crespo via bitcoin-dev]

Yes.

1. SegWit transactions spend less "weight", which is limited for every
block. Base transaction data weights as much as 4x the witness data.

2. SegWit signatures can be cheaper to verify (linear instead of
quadratic). Prior to this, DoS attacks were possible by using forged
transactions including signatures which could take several minutes to
verify.

The immediate result of this is that miners can fit more transactions
into a block and at the same time spend less power building the blocks.

Post by Dan Bryant via bitcoin-dev
Is there any incentive for miners to pick segwit transactions over
non-segwit transaction.  Do they require less, equal, or more compute to
process?
On Nov 20, 2017 11:46 AM, "Johnson Lau via bitcoin-dev"
We can’t “just compute the Transaction ID the same way the hash for
signing the transaction is computed” because with different SIGHASH
flags, there are 6 (actually 256) ways to hash a transaction.
Also, changing the definition of TxID is a hardfork change, i.e.
everyone are required to upgrade or a chain split will happen.
It is possible to use “normalised TxID” (BIP140) to fix malleability
issue. As a softfork, BIP140 doesn’t change the definition of TxID.
Instead, the normalised txid (i.e. txid with scriptSig removed) is
used when making signature. Comparing with segwit (BIP141), BIP140
does not have the side-effect of block size increase, and doesn’t
provide any incentive to control the size of UTXO set. Also, BIP140
makes the UTXO set permanently bigger, as the database needs to
store both txid and normalised txid

Post by Dan Bryant via bitcoin-dev
On 21 Nov 2017, at 1:24 AM, Praveen Baratam via bitcoin-dev
Bitcoin Noob here. Please forgive my ignorance.
From what I understand, in SegWit, the transaction needs to be
serialized into a data structure that is different from the
current one where signatures are separated from the rest of the
transaction data.
Why change the format at all? Why cant we just compute the
Transaction ID the same way the hash for signing the transaction
is computed?
--
Dr. Praveen Baratam
about.me <http://about.me/praveen.baratam>
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[CANNON via bitcoin-dev]

Post by Adán Sánchez de Pedro Crespo via bitcoin-dev
2. SegWit signatures can be cheaper to verify (linear instead of
quadratic). Prior to this, DoS attacks were possible by using forged
transactions including signatures which could take several minutes to
verify.

Where can I find more resources on this described DoS attack?
And how does SegWit prevent this if using SegWit transactions are not enforced?

Thanks

[Gregory Maxwell via bitcoin-dev]

On Mon, Nov 20, 2017 at 5:24 PM, Praveen Baratam via bitcoin-dev

Post by Praveen Baratam via bitcoin-dev
Bitcoin Noob here. Please forgive my ignorance.
From what I understand, in SegWit, the transaction needs to be serialized
into a data structure that is different from the current one where
signatures are separated from the rest of the transaction data.
Why change the format at all? Why cant we just compute the Transaction ID
the same way the hash for signing the transaction is computed?

That is effectively what segwit does, upto engineering minutia and
compatibility details.

Segwit does not serialize transactions in to a data structure where
signatures are separated from the rest of the transaction data; this
is a misunderstanding. The "segregated" refers to them being excluded
from the TXID. The serialization of segwit on the p2p network in
transactions and in blocks encodes the witness field inside the
transactions, immediately prior to the nlocktime field.