📅 Original date posted:2017-05-09
📝 Original message:The discount is designed to reduce UTXO bloat primarily, witness spam
data would not make it into the UTXO set. The discount brings the fee
of a transaction more in line with the actual costs to the network for
the transaction. A miner spamming the network with 4MB witness blocks
would have very little impact on the UTXO size compared with 1MB
non-witness blocks. UTXO size is a bigger issue than blockchain size
since full nodes can't prune the UTXO set.
The discount of 75% for the SegWit softfork doesn't really have any
effect on future hard forks as it can always be adjusted as needed
later on as part of a HF.
On Tue, May 9, 2017 at 8:49 AM, Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> This [1] article says the current discount prevents witness spam. Witness
> spam is free space in the witness part of the block that can be filled by
> miners to create bigger blocks with almost no cost for the benefit a cluster
> of miners with low latency, increasing centralization.
>
> The 75% discount does not prevent it, but on the contrary leaves a lot of
> extra witness space for spam.
>
> If the maximum block weight is set to 2.7M, each byte of non-witness block
> costs 1.7, and each byte of witness costs 1, then a normal filled block
> would be 2.7M bytes (1.7+1), and there will be no need to create ever a 4
> Mbyte block. The worst case would be the average case, and the transaction
> rate would be the maximum possible.
>
> The current 75% discount can only achieve more transactions per second if
> the type of transactions change. Therefore the current 75% discount only
> makes the block size worst case worse (4 Mbytes when it should be 2.7
> Mbytes).
>
> 80% of all inputs/outputs are P2PKH. The only way to make use of the extra
> witness
> space If most P2PKH transactions are replaced by multisigs (typically for
> LN).
>
> So it seems the 75% discount has been chosen with the idea that in the
> future the current transaction pattern will shift towards multisigs. This is
> not a bad idea, as it's the only direction Bitcoin can scale without a HF.
> But it's a bad idea if we end up doing, for example, a 2X blocksize increase
> HF in the future. In that case it's much better to use a 50% witness
> discount, and do not make scaling risky by making the worse case block size
> 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes.
>
> I've uploaded the code here:
> https://github.com/SergioDemianLerner/SegwitStats
>
> [1]
> https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e.
>
>
> On Mon, May 8, 2017 at 8:47 PM, Alphonse Pace via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Sergio,
>>
>> I'm not sure what the data you present has to do with the discount. A 75%
>> discount prevents witness spam precisely because it is 75%, nothing more.
>> The current usage simply gives a guideline on how much capacity is gained
>> through a particular discount. With the data you show, it would imply that
>> those blocks, with SegWit used where possible, would result in blocks of
>> ~1.8MB.
>>
>>
>>
>> On Mon, May 8, 2017 at 5:42 PM, Sergio Demian Lerner via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> I have processed 1000 blocks starting from Block #461653.
>>>
>>> I computed several metrics, including the supposed size of witness data
>>> and non-witness data (onchain), assuming all P2SH inputs/outputs are
>>> converted to P2PWSH and all P2PKH inputs/outputs are converted to P2WPKH.
>>>
>>> This takes into account that other types of transactions will not be
>>> modified by Segwit (e.g. OP_RETURN outputs, or P2PK). This analysis doesn't
>>> take into account that LN transactions may affect the current state,
>>> increasing the segwit/nosegwit ratio.
>>>
>>> Among a lot of information, I've got the following real world results...
>>>
>>> acMainChainSpace =352608924
>>> acSegwitSpace =599400403
>>> Ratio segwit/nosegwit=1.6999
>>>
>>> This implies that the 75% that discount is not the best option to prevent
>>> witness spam in a block of 4 MB, as stated in
>>> https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e.
>>>
>>> The non-witness data weight factor should not be 4 but 2.35. The closest
>>> integer value is 2, which leads to a 50% witness discount.
>>>
>>> The Bitcoinj source code is available for anyone to review. I encourage
>>> anyone to re-compute this with another utility to cross-check. Maybe Antoine
>>> Le Calvez (p2sh.info) would like to double-check.
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> 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
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
James Hilliard [ARCHIVE] /
npub10r…kgk2d
2023-06-07 18:00:57
in reply to nevent1q…3xeg
Author Public Key
npub10r9d6edmnrljk59wsf06zqp494l3qtjpa3w245hy6t5euqxlzw2qdkgk2dPublished at
2023-06-07 18:00:57Event JSON
{
"id": "e58d6c0586316cd37bb61f5375f07b6c29c8d35de9f7579628e414a4d7829cc2",
"pubkey": "78cadd65bb98ff2b50ae825fa100352d7f102e41ec5caad2e4d2e99e00df1394",
"created_at": 1686160857,
"kind": 1,
"tags": [
[
"e",
"4aacc31e765e9e31a3d8eb41d296ff5dc213462528e2e5335cec5ccb80e70465",
"",
"root"
],
[
"e",
"ce4f55ed2b3eb88f92a3f63ba4113983b588dd6d88c4532ba28d0197d618e5a3",
"",
"reply"
],
[
"p",
"4b38603408f5be002091210e869a4ca86fc2aa1ffd0871036a0668068ee626ee"
]
],
"content": "📅 Original date posted:2017-05-09\n📝 Original message:The discount is designed to reduce UTXO bloat primarily, witness spam\ndata would not make it into the UTXO set. The discount brings the fee\nof a transaction more in line with the actual costs to the network for\nthe transaction. A miner spamming the network with 4MB witness blocks\nwould have very little impact on the UTXO size compared with 1MB\nnon-witness blocks. UTXO size is a bigger issue than blockchain size\nsince full nodes can't prune the UTXO set.\n\nThe discount of 75% for the SegWit softfork doesn't really have any\neffect on future hard forks as it can always be adjusted as needed\nlater on as part of a HF.\n\nOn Tue, May 9, 2017 at 8:49 AM, Sergio Demian Lerner via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e This [1] article says the current discount prevents witness spam. Witness\n\u003e spam is free space in the witness part of the block that can be filled by\n\u003e miners to create bigger blocks with almost no cost for the benefit a cluster\n\u003e of miners with low latency, increasing centralization.\n\u003e\n\u003e The 75% discount does not prevent it, but on the contrary leaves a lot of\n\u003e extra witness space for spam.\n\u003e\n\u003e If the maximum block weight is set to 2.7M, each byte of non-witness block\n\u003e costs 1.7, and each byte of witness costs 1, then a normal filled block\n\u003e would be 2.7M bytes (1.7+1), and there will be no need to create ever a 4\n\u003e Mbyte block. The worst case would be the average case, and the transaction\n\u003e rate would be the maximum possible.\n\u003e\n\u003e The current 75% discount can only achieve more transactions per second if\n\u003e the type of transactions change. Therefore the current 75% discount only\n\u003e makes the block size worst case worse (4 Mbytes when it should be 2.7\n\u003e Mbytes).\n\u003e\n\u003e 80% of all inputs/outputs are P2PKH. The only way to make use of the extra\n\u003e witness\n\u003e space If most P2PKH transactions are replaced by multisigs (typically for\n\u003e LN).\n\u003e\n\u003e So it seems the 75% discount has been chosen with the idea that in the\n\u003e future the current transaction pattern will shift towards multisigs. This is\n\u003e not a bad idea, as it's the only direction Bitcoin can scale without a HF.\n\u003e But it's a bad idea if we end up doing, for example, a 2X blocksize increase\n\u003e HF in the future. In that case it's much better to use a 50% witness\n\u003e discount, and do not make scaling risky by making the worse case block size\n\u003e 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes.\n\u003e\n\u003e I've uploaded the code here:\n\u003e https://github.com/SergioDemianLerner/SegwitStats\n\u003e\n\u003e [1]\n\u003e https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e.\n\u003e\n\u003e\n\u003e On Mon, May 8, 2017 at 8:47 PM, Alphonse Pace via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e Sergio,\n\u003e\u003e\n\u003e\u003e I'm not sure what the data you present has to do with the discount. A 75%\n\u003e\u003e discount prevents witness spam precisely because it is 75%, nothing more.\n\u003e\u003e The current usage simply gives a guideline on how much capacity is gained\n\u003e\u003e through a particular discount. With the data you show, it would imply that\n\u003e\u003e those blocks, with SegWit used where possible, would result in blocks of\n\u003e\u003e ~1.8MB.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On Mon, May 8, 2017 at 5:42 PM, Sergio Demian Lerner via bitcoin-dev\n\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e I have processed 1000 blocks starting from Block #461653.\n\u003e\u003e\u003e\n\u003e\u003e\u003e I computed several metrics, including the supposed size of witness data\n\u003e\u003e\u003e and non-witness data (onchain), assuming all P2SH inputs/outputs are\n\u003e\u003e\u003e converted to P2PWSH and all P2PKH inputs/outputs are converted to P2WPKH.\n\u003e\u003e\u003e\n\u003e\u003e\u003e This takes into account that other types of transactions will not be\n\u003e\u003e\u003e modified by Segwit (e.g. OP_RETURN outputs, or P2PK). This analysis doesn't\n\u003e\u003e\u003e take into account that LN transactions may affect the current state,\n\u003e\u003e\u003e increasing the segwit/nosegwit ratio.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Among a lot of information, I've got the following real world results...\n\u003e\u003e\u003e\n\u003e\u003e\u003e acMainChainSpace =352608924\n\u003e\u003e\u003e acSegwitSpace =599400403\n\u003e\u003e\u003e Ratio segwit/nosegwit=1.6999\n\u003e\u003e\u003e\n\u003e\u003e\u003e This implies that the 75% that discount is not the best option to prevent\n\u003e\u003e\u003e witness spam in a block of 4 MB, as stated in\n\u003e\u003e\u003e https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e.\n\u003e\u003e\u003e\n\u003e\u003e\u003e The non-witness data weight factor should not be 4 but 2.35. The closest\n\u003e\u003e\u003e integer value is 2, which leads to a 50% witness discount.\n\u003e\u003e\u003e\n\u003e\u003e\u003e The Bitcoinj source code is available for anyone to review. I encourage\n\u003e\u003e\u003e anyone to re-compute this with another utility to cross-check. Maybe Antoine\n\u003e\u003e\u003e Le Calvez (p2sh.info) would like to double-check.\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e\n\u003e\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 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\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",
"sig": "e06b5e7490ac51f0c931642aa372a40f76be61e69759ece46ce3be2d4b01c02a39969777d5070e08717487aad09fd40b6ffeb7ec381701d739384d078600abac"
}