📅 Original date posted:2016-02-08
📝 Original message:Thanks for this proposal. Just some quick response:
1. The segwit hardfork (BIP HF) could be deployed with BIP141 (segwit
softfork). BIP141 doesn't need grace period. BIP HF will have around 1 year
of grace period.
2. Threshold is 95%. Using 4 versoin bits: a) BIP 141; b) BIP HF; c) BIP 141
if BIP HF has already got 95%; d) BIP HF if BIP141 has already got 95%.
Voting a and c (or b and d) at the same time is invalid. BIP 141 is
activated if a>95% or (a+c>95% and b+d>95%). BIP HF is activated if b>95% or
(a+c>95% and b+d>95%).
3. Fix time warp attack: this may break some SPV implementation
4. Limiting non-segwit inputs may make some existing signed tx invalid. My
proposal is: a) count the number of non-segwit sigop in a tx, including
those in unexecuted branch (sigop); b) measure the tx size without scripgSig
(size); c) a new rule is SUM(sigop*size) < some_value . This allows
calculation without actually running the script.
-----Original Message-----
From: bitcoin-dev-bounces at lists.linuxfoundation.org
[mailto:bitcoin-dev-bounces at lists.linuxfoundation.org] On Behalf Of Matt
Corallo via bitcoin-dev
Sent: Tuesday, 9 February, 2016 03:27
To: Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
Subject: [bitcoin-dev] On Hardforks in the Context of SegWit
Hi all,
I believe we, today, have a unique opportunity to begin to close the book on
the short-term scaling debate.
First a little background. The scaling debate that has been gripping the
Bitcoin community for the past half year has taken an interesting turn in
2016. Until recently, there have been two distinct camps - one proposing a
significant change to the consensus-enforced block size limit to allow for
more on-blockchain transactions and the other opposing such a change,
suggesting instead that scaling be obtained by adding more flexible systems
on top of the blockchain. At this point, however, the entire Bitcoin
community seems to have unified around a single vision - roughly 2MB of
transactions per block, whether via Segregated Witness or via a hard fork,
is something that can be both technically supported and which adds more
headroom before second-layer technologies must be in place. Additionally, it
seems that the vast majority of the community agrees that segregated witness
should be implemented in the near future and that hard forks will be a
necessity at some point, and I don't believe it should be controversial
that, as we have never done a hard fork before, gaining experience by
working towards a hard fork now is a good idea.
With the apparent agreement in the community, it is incredibly disheartening
that there is still so much strife, creating a toxic environment in which
developers are not able to work, companies are worried about their future
ability to easily move Bitcoins, and investors are losing confidence. The
way I see it, this broad unification of visions across all parts of the
community places the burden of selecting the most technically-sound way to
achieve that vision squarely on the development community.
Sadly, the strife is furthered by the huge risks involved in a hard fork in
the presence of strife, creating a toxic cycle which prevents a safe hard
fork. While there has been talk of doing an "emergency hardfork" as an
option, and while I do believe this is possible, it is not something that
will be easy, especially for something as controversial as rising fees.
Given that we have never done a hard fork before, being very careful and
deliberate in doing so is critical, and the technical community working
together to plan for all of the things that might go wrong is key to not
destroying significant value.
As such, I'd like to ask everyone involved to take this opportunity to
"reset", forgive past aggressions, and return the technical debates to
technical forums (ie here, IRC, etc).
As what a hard fork should look like in the context of segwit has never
(!) been discussed in any serious sense, I'd like to kick off such a
discussion with a (somewhat) specific proposal.
First some design notes:
* I think a key design feature should be taking this opportunity to add
small increases in decentralization pressure, where possible.
* Due to the several non-linear validation time issues in transaction
validation which are fixed by SegWit's signature-hashing changes, I strongly
believe any hard fork proposal which changes the block size should rely on
SegWit's existence.
* As with any hard fork proposal, its easy to end up pulling in hundreds of
small fixes for any number of protocol annoyances. In order to avoid doing
this, we should try hard to stick with a few simple changes.
Here is a proposed outline (to activate only after SegWit and with the
currently-proposed version of SegWit):
1) The segregated witness discount is changed from 75% to 50%. The block
size limit (ie transactions + witness/2) is set to 1.5MB. This gives a
maximum block size of 3MB and a "network-upgraded" block size of roughly
2.1MB. This still significantly discounts script data which is kept out of
the UTXO set, while keeping the maximum-sized block limited.
2) In order to prevent significant blowups in the cost to validate
pessimistic blocks, we must place additional limits on the size of many
non-segwit transactions. scriptPubKeys are now limited to 100 bytes in size
and may not contain OP_CODESEPARATOR, scriptSigs must be push-only (ie no
non-push opcodes), and transactions are only allowed to contain up to 20
non-segwit inputs. Together these limits limit total-bytes-hashed in block
validation to under 200MB without any possibility of making existing outputs
unspendable and without adding additional per-block limits which make
transaction-selection-for-mining difficult in the face of attacks or
non-standard transactions. Though 200MB of hashing (roughly 2 seconds of
hash-time on my high-end
workstation) is pretty strongly centralizing, limiting transactions to fewer
than 20 inputs seems arbitrarily low.
Along similar lines, we may wish to switch MAX_BLOCK_SIGOPS from
1-per-50-bytes across the entire block to a per-transaction limit which is
slightly looser (though not too much looser - even with libsecp256k1
1-per-50-bytes represents 2 seconds of single-threaded validation in just
sigops on my high-end workstation).
3) Move SegWit's generic commitments from an OP_RETURN output to a second
branch in the merkle tree. Depending on the timeline this may be something
to skip - once there is tooling for dealing with the extra OP_RETURN output
as a generic commitment, the small efficiency gain for applications checking
the witness of only one transaction or checking a non-segwit commitment may
not be worth it.
4) Instead of requiring the first four bytes of the previous block hash
field be 0s, we allow them to contain any value. This allows Bitcoin mining
hardware to reduce the required logic, making it easier to produce
competitive hardware [1].
I'll deliberately leave discussion of activation method out of this
proposal. Both jl2012 and Luke-Jr recently begun some discussions about
methods for activation on this list, and I'd love to see those continue.
If folks think a hard fork should go ahead without SPV clients having a say,
we could table #4, or activate #4 a year or two after 1-3 activate.
[1] Simpler here may not be entirely true. There is potential for
optimization if you brute force the SHA256 midstate, but if nothing else,
this will prevent there being a strong incentive to use the version field as
nonce space. This may need more investigation, as we may wish to just set
the minimum difficulty higher so that we can add more than 4 nonce-bytes.
Obviously we cannot reasonably move forward with a hard fork as long as the
contention in the community continues. Still, I'm confident continuing to
work towards SegWit as a 2MB-ish soft-fork in the short term with some plans
on what a hard fork should look like if we can form broad consensus can go a
long way to resolving much of the contention we've seen.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
jl2012 at xbt.hk [ARCHIVE] /
npub1kc…wjfw4
2023-06-07 17:48:54
in reply to nevent1q…0nu8
Author Public Key
npub1kc0zulxt7j4a0ayhzhrz7jk84y7tm4026qcky7w97hlfkxxap24qnwjfw4Published at
2023-06-07 17:48:54Event JSON
{
"id": "62c3d4080319b5a48d87e7b7cdf20372ad99ec8a2e4382c32d84df600d029dfc",
"pubkey": "b61e2e7ccbf4abd7f49715c62f4ac7a93cbdd5ead0316279c5f5fe9b18dd0aaa",
"created_at": 1686160134,
"kind": 1,
"tags": [
[
"e",
"8c25de74ae7131786de7d5ab012e48bad7eff95963972248b7442bdb60a9ffb5",
"",
"root"
],
[
"e",
"a75008b9a813183e76b7e60239bd46b4246da35f6ef7de758c2201669f5c00a0",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2016-02-08\n📝 Original message:Thanks for this proposal. Just some quick response:\n\n1. The segwit hardfork (BIP HF) could be deployed with BIP141 (segwit\nsoftfork). BIP141 doesn't need grace period. BIP HF will have around 1 year\nof grace period.\n\n2. Threshold is 95%. Using 4 versoin bits: a) BIP 141; b) BIP HF; c) BIP 141\nif BIP HF has already got 95%; d) BIP HF if BIP141 has already got 95%.\nVoting a and c (or b and d) at the same time is invalid. BIP 141 is\nactivated if a\u003e95% or (a+c\u003e95% and b+d\u003e95%). BIP HF is activated if b\u003e95% or\n(a+c\u003e95% and b+d\u003e95%).\n\n3. Fix time warp attack: this may break some SPV implementation\n\n4. Limiting non-segwit inputs may make some existing signed tx invalid. My\nproposal is: a) count the number of non-segwit sigop in a tx, including\nthose in unexecuted branch (sigop); b) measure the tx size without scripgSig\n(size); c) a new rule is SUM(sigop*size) \u003c some_value . This allows\ncalculation without actually running the script.\n\n\n-----Original Message-----\nFrom: bitcoin-dev-bounces at lists.linuxfoundation.org\n[mailto:bitcoin-dev-bounces at lists.linuxfoundation.org] On Behalf Of Matt\nCorallo via bitcoin-dev\nSent: Tuesday, 9 February, 2016 03:27\nTo: Bitcoin Dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\nSubject: [bitcoin-dev] On Hardforks in the Context of SegWit\n\nHi all,\n\nI believe we, today, have a unique opportunity to begin to close the book on\nthe short-term scaling debate.\n\nFirst a little background. The scaling debate that has been gripping the\nBitcoin community for the past half year has taken an interesting turn in\n2016. Until recently, there have been two distinct camps - one proposing a\nsignificant change to the consensus-enforced block size limit to allow for\nmore on-blockchain transactions and the other opposing such a change,\nsuggesting instead that scaling be obtained by adding more flexible systems\non top of the blockchain. At this point, however, the entire Bitcoin\ncommunity seems to have unified around a single vision - roughly 2MB of\ntransactions per block, whether via Segregated Witness or via a hard fork,\nis something that can be both technically supported and which adds more\nheadroom before second-layer technologies must be in place. Additionally, it\nseems that the vast majority of the community agrees that segregated witness\nshould be implemented in the near future and that hard forks will be a\nnecessity at some point, and I don't believe it should be controversial\nthat, as we have never done a hard fork before, gaining experience by\nworking towards a hard fork now is a good idea.\n\nWith the apparent agreement in the community, it is incredibly disheartening\nthat there is still so much strife, creating a toxic environment in which\ndevelopers are not able to work, companies are worried about their future\nability to easily move Bitcoins, and investors are losing confidence. The\nway I see it, this broad unification of visions across all parts of the\ncommunity places the burden of selecting the most technically-sound way to\nachieve that vision squarely on the development community.\n\nSadly, the strife is furthered by the huge risks involved in a hard fork in\nthe presence of strife, creating a toxic cycle which prevents a safe hard\nfork. While there has been talk of doing an \"emergency hardfork\" as an\noption, and while I do believe this is possible, it is not something that\nwill be easy, especially for something as controversial as rising fees.\nGiven that we have never done a hard fork before, being very careful and\ndeliberate in doing so is critical, and the technical community working\ntogether to plan for all of the things that might go wrong is key to not\ndestroying significant value.\n\nAs such, I'd like to ask everyone involved to take this opportunity to\n\"reset\", forgive past aggressions, and return the technical debates to\ntechnical forums (ie here, IRC, etc).\n\nAs what a hard fork should look like in the context of segwit has never\n(!) been discussed in any serious sense, I'd like to kick off such a\ndiscussion with a (somewhat) specific proposal.\n\nFirst some design notes:\n* I think a key design feature should be taking this opportunity to add\nsmall increases in decentralization pressure, where possible.\n* Due to the several non-linear validation time issues in transaction\nvalidation which are fixed by SegWit's signature-hashing changes, I strongly\nbelieve any hard fork proposal which changes the block size should rely on\nSegWit's existence.\n* As with any hard fork proposal, its easy to end up pulling in hundreds of\nsmall fixes for any number of protocol annoyances. In order to avoid doing\nthis, we should try hard to stick with a few simple changes.\n\nHere is a proposed outline (to activate only after SegWit and with the\ncurrently-proposed version of SegWit):\n\n1) The segregated witness discount is changed from 75% to 50%. The block\nsize limit (ie transactions + witness/2) is set to 1.5MB. This gives a\nmaximum block size of 3MB and a \"network-upgraded\" block size of roughly\n2.1MB. This still significantly discounts script data which is kept out of\nthe UTXO set, while keeping the maximum-sized block limited.\n\n2) In order to prevent significant blowups in the cost to validate\npessimistic blocks, we must place additional limits on the size of many\nnon-segwit transactions. scriptPubKeys are now limited to 100 bytes in size\nand may not contain OP_CODESEPARATOR, scriptSigs must be push-only (ie no\nnon-push opcodes), and transactions are only allowed to contain up to 20\nnon-segwit inputs. Together these limits limit total-bytes-hashed in block\nvalidation to under 200MB without any possibility of making existing outputs\nunspendable and without adding additional per-block limits which make\ntransaction-selection-for-mining difficult in the face of attacks or\nnon-standard transactions. Though 200MB of hashing (roughly 2 seconds of\nhash-time on my high-end\nworkstation) is pretty strongly centralizing, limiting transactions to fewer\nthan 20 inputs seems arbitrarily low.\n\nAlong similar lines, we may wish to switch MAX_BLOCK_SIGOPS from\n1-per-50-bytes across the entire block to a per-transaction limit which is\nslightly looser (though not too much looser - even with libsecp256k1\n1-per-50-bytes represents 2 seconds of single-threaded validation in just\nsigops on my high-end workstation).\n\n3) Move SegWit's generic commitments from an OP_RETURN output to a second\nbranch in the merkle tree. Depending on the timeline this may be something\nto skip - once there is tooling for dealing with the extra OP_RETURN output\nas a generic commitment, the small efficiency gain for applications checking\nthe witness of only one transaction or checking a non-segwit commitment may\nnot be worth it.\n\n4) Instead of requiring the first four bytes of the previous block hash\nfield be 0s, we allow them to contain any value. This allows Bitcoin mining\nhardware to reduce the required logic, making it easier to produce\ncompetitive hardware [1].\n\nI'll deliberately leave discussion of activation method out of this\nproposal. Both jl2012 and Luke-Jr recently begun some discussions about\nmethods for activation on this list, and I'd love to see those continue.\nIf folks think a hard fork should go ahead without SPV clients having a say,\nwe could table #4, or activate #4 a year or two after 1-3 activate.\n\n\n[1] Simpler here may not be entirely true. There is potential for\noptimization if you brute force the SHA256 midstate, but if nothing else,\nthis will prevent there being a strong incentive to use the version field as\nnonce space. This may need more investigation, as we may wish to just set\nthe minimum difficulty higher so that we can add more than 4 nonce-bytes.\n\n\n\n\nObviously we cannot reasonably move forward with a hard fork as long as the\ncontention in the community continues. Still, I'm confident continuing to\nwork towards SegWit as a 2MB-ish soft-fork in the short term with some plans\non what a hard fork should look like if we can form broad consensus can go a\nlong way to resolving much of the contention we've seen.\n_______________________________________________\nbitcoin-dev mailing list\nbitcoin-dev at lists.linuxfoundation.org\nhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "e36495988c5fc9a7e4bf38dad58b482749a5b1e368270d906ec635300b08f502cd012d2e0994cb086aaf7edd519b5778b983c4815132191b6e92d29578f1eb79"
}