đź“… Original date posted:2017-11-21
đź“ť Original message: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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Adán Sánchez de Pedro Crespo
CTO, Stampery Inc.
San Francisco - Madrid
Adán Sánchez de Pedro Crespo [ARCHIVE] /
npub1gt…khzxn
2023-06-07 18:07:51
in reply to nevent1q…a8tj
Author Public Key
npub1gtysrlxd5svywueh4767hrj3wfnx2gcx2wdtnnkhr9k57drhh52q3khzxnPublished at
2023-06-07 18:07:51Event JSON
{
"id": "05bc5f4356ad7e2e13abf43f5c53df692917de964340370f0bd3e47470c5030c",
"pubkey": "42c901fccda418477337afb5eb8e517266652306539ab9ced7196d4f3477bd14",
"created_at": 1686161271,
"kind": 1,
"tags": [
[
"e",
"eee7506507e946de4c59c91cb3baa47c489b31bb507a0da8ae8433013d8e1ac7",
"",
"root"
],
[
"e",
"7f54aa21b4e8255f52bbae901a0fc4bdbf06582828eb6cf86dc5a30c3e59e621",
"",
"reply"
],
[
"p",
"6063083ef1199a29e8b1099d469026bbc00eeedb3f1c10d5bcb7f907a5e32e0c"
]
],
"content": "📅 Original date posted:2017-11-21\n📝 Original message:Yes.\n\n1. SegWit transactions spend less \"weight\", which is limited for every\nblock. Base transaction data weights as much as 4x the witness data.\n\n2. SegWit signatures can be cheaper to verify (linear instead of\nquadratic). Prior to this, DoS attacks were possible by using forged\ntransactions including signatures which could take several minutes to\nverify.\n\nThe immediate result of this is that miners can fit more transactions\ninto a block and at the same time spend less power building the blocks.\n\nOn 20.11.2017 19:04, Dan Bryant via bitcoin-dev wrote:\n\u003e Is there any incentive for miners to pick segwit transactions over\n\u003e non-segwit transaction. Do they require less, equal, or more compute to\n\u003e process?\n\u003e \n\u003e On Nov 20, 2017 11:46 AM, \"Johnson Lau via bitcoin-dev\"\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e \n\u003e We can’t “just compute the Transaction ID the same way the hash for\n\u003e signing the transaction is computed” because with different SIGHASH\n\u003e flags, there are 6 (actually 256) ways to hash a transaction.\n\u003e \n\u003e Also, changing the definition of TxID is a hardfork change, i.e.\n\u003e everyone are required to upgrade or a chain split will happen.\n\u003e \n\u003e It is possible to use “normalised TxID” (BIP140) to fix malleability\n\u003e issue. As a softfork, BIP140 doesn’t change the definition of TxID.\n\u003e Instead, the normalised txid (i.e. txid with scriptSig removed) is\n\u003e used when making signature. Comparing with segwit (BIP141), BIP140\n\u003e does not have the side-effect of block size increase, and doesn’t\n\u003e provide any incentive to control the size of UTXO set. Also, BIP140\n\u003e makes the UTXO set permanently bigger, as the database needs to\n\u003e store both txid and normalised txid\n\u003e \n\u003e\u003e On 21 Nov 2017, at 1:24 AM, Praveen Baratam via bitcoin-dev\n\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e\u003e\n\u003e\u003e Bitcoin Noob here. Please forgive my ignorance.\n\u003e\u003e\n\u003e\u003e From what I understand, in SegWit, the transaction needs to be\n\u003e\u003e serialized into a data structure that is different from the\n\u003e\u003e current one where signatures are separated from the rest of the\n\u003e\u003e transaction data.\n\u003e\u003e\n\u003e\u003e Why change the format at all? Why cant we just compute the\n\u003e\u003e Transaction ID the same way the hash for signing the transaction\n\u003e\u003e is computed?\n\u003e\u003e\n\u003e\u003e -- \n\u003e\u003e Dr. Praveen Baratam\n\u003e\u003e\n\u003e\u003e about.me \u003chttp://about.me/praveen.baratam\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e \u003chttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\u003e\n\u003e \n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003chttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\u003e\n\u003e \n\u003e \n\u003e \n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\n-- \nAdán Sánchez de Pedro Crespo\nCTO, Stampery Inc.\nSan Francisco - Madrid",
"sig": "b450b3c0fb83d2c16013d5d573d78235c836c15a2cb69f28a24dea838c6db6c24ad1e0f8c9f9c4395ef62cdfab3954fbd981cddccaceed012c12fbf52973b763"
}