public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Adán Sánchez de Pedro Crespo" <adan@stampery.co>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Why SegWit Anyway?
Date: Tue, 21 Nov 2017 14:16:48 +0100	[thread overview]
Message-ID: <15502d41-61f2-9a17-a4cf-03cd20a87368@stampery.com> (raw)
In-Reply-To: <CAAUFj1091C3xXL+2j1EovE2j_2kDYsjP_O4ZOKBaxmHuKN=1Lg@mail.gmail.com>

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


  parent reply	other threads:[~2017-11-21 13:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=15502d41-61f2-9a17-a4cf-03cd20a87368@stampery.com \
    --to=adan@stampery.co \
    --cc=adan@stampery.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox