* [bitcoin-dev] Why SegWit Anyway?
@ 2017-11-20 17:24 Praveen Baratam
2017-11-20 17:39 ` Ariel Lorenzo-Luaces
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: Praveen Baratam @ 2017-11-20 17:24 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 461 bytes --]
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>
[-- Attachment #2: Type: text/html, Size: 1375 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [bitcoin-dev] Why SegWit Anyway? 2017-11-20 17:24 [bitcoin-dev] Why SegWit Anyway? Praveen Baratam @ 2017-11-20 17:39 ` Ariel Lorenzo-Luaces 2017-11-20 17:45 ` Johnson Lau 2017-11-20 18:59 ` Gregory Maxwell 2 siblings, 0 replies; 10+ messages in thread From: Ariel Lorenzo-Luaces @ 2017-11-20 17:39 UTC (permalink / raw) To: Praveen Baratam, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1566 bytes --] 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 On Nov 20, 2017, 9:29 AM, at 9:29 AM, Praveen Baratam via bitcoin-dev <bitcoin-dev@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? > >-- >Dr. Praveen Baratam > >about.me <http://about.me/praveen.baratam> > > >------------------------------------------------------------------------ > >_______________________________________________ >bitcoin-dev mailing list >bitcoin-dev@lists•linuxfoundation.org >https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 2903 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Why SegWit Anyway? 2017-11-20 17:24 [bitcoin-dev] Why SegWit Anyway? Praveen Baratam 2017-11-20 17:39 ` Ariel Lorenzo-Luaces @ 2017-11-20 17:45 ` Johnson Lau [not found] ` <CAAUFj10ZRQrtEzB_2wp-WS8Q-FGcSegpc_Z6kqvqnDLzNn=DrA@mail.gmail.com> 2017-11-20 18:07 ` Praveen Baratam 2017-11-20 18:59 ` Gregory Maxwell 2 siblings, 2 replies; 10+ messages in thread From: Johnson Lau @ 2017-11-20 17:45 UTC (permalink / raw) To: Praveen Baratam, bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1643 bytes --] 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-dev@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? > > -- > Dr. Praveen Baratam > > about.me <http://about.me/praveen.baratam>_______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 3379 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <CAAUFj10ZRQrtEzB_2wp-WS8Q-FGcSegpc_Z6kqvqnDLzNn=DrA@mail.gmail.com>]
[parent not found: <CAAUFj11_Vh2K4MrmuBre5KaX6F16Jg3PYAsj6SSfzoYYRz_WyA@mail.gmail.com>]
* Re: [bitcoin-dev] Why SegWit Anyway? [not found] ` <CAAUFj11_Vh2K4MrmuBre5KaX6F16Jg3PYAsj6SSfzoYYRz_WyA@mail.gmail.com> @ 2017-11-20 18:04 ` Dan Bryant 2017-11-21 13:10 ` Steve Shadders 2017-11-21 13:16 ` Adán Sánchez de Pedro Crespo 0 siblings, 2 replies; 10+ messages in thread From: Dan Bryant @ 2017-11-20 18:04 UTC (permalink / raw) To: bitcoin-dev, Johnson Lau [-- Attachment #1: Type: text/plain, Size: 2075 bytes --] 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-dev@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-dev@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? -- Dr. Praveen Baratam about.me <http://about.me/praveen.baratam> _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists•linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists•linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 4115 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Why SegWit Anyway? 2017-11-20 18:04 ` Dan Bryant @ 2017-11-21 13:10 ` Steve Shadders 2017-11-21 13:16 ` Adán Sánchez de Pedro Crespo 1 sibling, 0 replies; 10+ messages in thread From: Steve Shadders @ 2017-11-21 13:10 UTC (permalink / raw) To: DKBryant, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2683 bytes --] 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" < bitcoin-dev@lists•linuxfoundation.org> wrote: > 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-dev@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-dev@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? > > -- > Dr. Praveen Baratam > > about.me <http://about.me/praveen.baratam> > _______________________________________________ > > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 5285 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Why SegWit Anyway? 2017-11-20 18:04 ` Dan Bryant 2017-11-21 13:10 ` Steve Shadders @ 2017-11-21 13:16 ` Adán Sánchez de Pedro Crespo 2017-11-25 15:41 ` CANNON 1 sibling, 1 reply; 10+ messages in thread From: Adán Sánchez de Pedro Crespo @ 2017-11-21 13:16 UTC (permalink / raw) To: 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. On 20.11.2017 19:04, Dan Bryant via bitcoin-dev wrote: > 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-dev@lists•linuxfoundation.org > <mailto:bitcoin-dev@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-dev@lists•linuxfoundation.org >> <mailto:bitcoin-dev@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? >> >> -- >> Dr. Praveen Baratam >> >> about.me <http://about.me/praveen.baratam> >> _______________________________________________ >> >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> <mailto:bitcoin-dev@lists•linuxfoundation.org> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > <mailto:bitcoin-dev@lists•linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- Adán Sánchez de Pedro Crespo CTO, Stampery Inc. San Francisco - Madrid ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Why SegWit Anyway? 2017-11-21 13:16 ` Adán Sánchez de Pedro Crespo @ 2017-11-25 15:41 ` CANNON 0 siblings, 0 replies; 10+ messages in thread From: CANNON @ 2017-11-25 15:41 UTC (permalink / raw) To: adan, Adán Sánchez de Pedro Crespo, Bitcoin Protocol Discussion On 11/21/2017 01:16 PM, Adán Sánchez de Pedro Crespo via bitcoin-dev wrote: > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Why SegWit Anyway? 2017-11-20 17:45 ` Johnson Lau [not found] ` <CAAUFj10ZRQrtEzB_2wp-WS8Q-FGcSegpc_Z6kqvqnDLzNn=DrA@mail.gmail.com> @ 2017-11-20 18:07 ` Praveen Baratam 2017-11-20 19:58 ` Johnson Lau 1 sibling, 1 reply; 10+ messages in thread From: Praveen Baratam @ 2017-11-20 18:07 UTC (permalink / raw) To: Johnson Lau; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 2130 bytes --] 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! ᐧ On Mon, Nov 20, 2017 at 11:15 PM, Johnson Lau <jl2012@xbt•hk> 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-dev@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? > > -- > Dr. Praveen Baratam > > about.me <http://about.me/praveen.baratam> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > -- Dr. Praveen Baratam about.me <http://about.me/praveen.baratam> [-- Attachment #2: Type: text/html, Size: 4715 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Why SegWit Anyway? 2017-11-20 18:07 ` Praveen Baratam @ 2017-11-20 19:58 ` Johnson Lau 0 siblings, 0 replies; 10+ messages in thread From: Johnson Lau @ 2017-11-20 19:58 UTC (permalink / raw) To: Praveen Baratam; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 2634 bytes --] 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. > On 21 Nov 2017, at 2:07 AM, Praveen Baratam <praveen.baratam@gmail•com> wrote: > > 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! > ᐧ > > On Mon, Nov 20, 2017 at 11:15 PM, Johnson Lau <jl2012@xbt•hk <mailto:jl2012@xbt•hk>> 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-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@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? >> >> -- >> Dr. Praveen Baratam >> >> about.me <http://about.me/praveen.baratam>_______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org> >> 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> [-- Attachment #2: Type: text/html, Size: 6227 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Why SegWit Anyway? 2017-11-20 17:24 [bitcoin-dev] Why SegWit Anyway? Praveen Baratam 2017-11-20 17:39 ` Ariel Lorenzo-Luaces 2017-11-20 17:45 ` Johnson Lau @ 2017-11-20 18:59 ` Gregory Maxwell 2 siblings, 0 replies; 10+ messages in thread From: Gregory Maxwell @ 2017-11-20 18:59 UTC (permalink / raw) To: Praveen Baratam, Bitcoin Protocol Discussion On Mon, Nov 20, 2017 at 5:24 PM, Praveen Baratam via bitcoin-dev <bitcoin-dev@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? 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-11-25 15:51 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-20 17:24 [bitcoin-dev] Why SegWit Anyway? Praveen Baratam
2017-11-20 17:39 ` Ariel Lorenzo-Luaces
2017-11-20 17:45 ` Johnson Lau
[not found] ` <CAAUFj10ZRQrtEzB_2wp-WS8Q-FGcSegpc_Z6kqvqnDLzNn=DrA@mail.gmail.com>
[not found] ` <CAAUFj11_Vh2K4MrmuBre5KaX6F16Jg3PYAsj6SSfzoYYRz_WyA@mail.gmail.com>
2017-11-20 18:04 ` Dan Bryant
2017-11-21 13:10 ` Steve Shadders
2017-11-21 13:16 ` Adán Sánchez de Pedro Crespo
2017-11-25 15:41 ` CANNON
2017-11-20 18:07 ` Praveen Baratam
2017-11-20 19:58 ` Johnson Lau
2017-11-20 18:59 ` Gregory Maxwell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox