📅 Original date posted:2016-02-08
📝 Original message:Hard forks should always come in response to some major crisis that all participants can agree is an actual crisis, as per the excellent rational here:
http://bitledger.info/why-a-hard-fork-should-be-fought-and-its-not-evil-to-discuss/
And here:
http://bitledger.info/hard-fork-risks-and-why-95-should-be-the-standard/
Also, if you’re going to do a hard fork, you’d better make the most of it as hard forks must be a *rare* world-is-ending-if-we-don’t-do-it thing (otherwise Bitcoin cannot be considered decentralized in any sense of the word).
So for any sort of hard fork, be sure to address the real threats and challenges that are facing Bitcoin today:
1. Mining centralization.
2. Privacy.
Best regards,
Greg Slepak
> On Feb 8, 2016, at 12:37 PM, jl2012--- via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> 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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160208/3e8cf754/attachment.sig>;
Tao Effect [ARCHIVE] /
npub1r0…vdpg3
2023-06-07 17:48:55
in reply to nevent1q…2err
Author Public Key
npub1r0g954grld59fuphzsypmuuhpdunq67f729afmp44h2mxvth2hts4vdpg3Published at
2023-06-07 17:48:55Event JSON
{
"id": "b211134dda040c8aa08e04f760e3460f017c0b1380fa106f34b62d86e7efccad",
"pubkey": "1bd05a5503fb6854f03714081df3970b79306bc9f28bd4ec35add5b3317755d7",
"created_at": 1686160135,
"kind": 1,
"tags": [
[
"e",
"8c25de74ae7131786de7d5ab012e48bad7eff95963972248b7442bdb60a9ffb5",
"",
"root"
],
[
"e",
"62c3d4080319b5a48d87e7b7cdf20372ad99ec8a2e4382c32d84df600d029dfc",
"",
"reply"
],
[
"p",
"b61e2e7ccbf4abd7f49715c62f4ac7a93cbdd5ead0316279c5f5fe9b18dd0aaa"
]
],
"content": "📅 Original date posted:2016-02-08\n📝 Original message:Hard forks should always come in response to some major crisis that all participants can agree is an actual crisis, as per the excellent rational here:\n\nhttp://bitledger.info/why-a-hard-fork-should-be-fought-and-its-not-evil-to-discuss/\n\nAnd here:\n\nhttp://bitledger.info/hard-fork-risks-and-why-95-should-be-the-standard/\n\nAlso, if you’re going to do a hard fork, you’d better make the most of it as hard forks must be a *rare* world-is-ending-if-we-don’t-do-it thing (otherwise Bitcoin cannot be considered decentralized in any sense of the word).\n\nSo for any sort of hard fork, be sure to address the real threats and challenges that are facing Bitcoin today:\n\n1. Mining centralization.\n2. Privacy.\n\nBest regards,\nGreg Slepak\n\n\u003e On Feb 8, 2016, at 12:37 PM, jl2012--- via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e Thanks for this proposal. Just some quick response:\n\u003e \n\u003e 1. The segwit hardfork (BIP HF) could be deployed with BIP141 (segwit\n\u003e softfork). BIP141 doesn't need grace period. BIP HF will have around 1 year\n\u003e of grace period.\n\u003e \n\u003e 2. Threshold is 95%. Using 4 versoin bits: a) BIP 141; b) BIP HF; c) BIP 141\n\u003e if BIP HF has already got 95%; d) BIP HF if BIP141 has already got 95%.\n\u003e Voting a and c (or b and d) at the same time is invalid. BIP 141 is\n\u003e activated if a\u003e95% or (a+c\u003e95% and b+d\u003e95%). BIP HF is activated if b\u003e95% or\n\u003e (a+c\u003e95% and b+d\u003e95%).\n\u003e \n\u003e 3. Fix time warp attack: this may break some SPV implementation\n\u003e \n\u003e 4. Limiting non-segwit inputs may make some existing signed tx invalid. My\n\u003e proposal is: a) count the number of non-segwit sigop in a tx, including\n\u003e those in unexecuted branch (sigop); b) measure the tx size without scripgSig\n\u003e (size); c) a new rule is SUM(sigop*size) \u003c some_value . This allows\n\u003e calculation without actually running the script.\n\u003e \n\u003e \n\u003e -----Original Message-----\n\u003e From: bitcoin-dev-bounces at lists.linuxfoundation.org\n\u003e [mailto:bitcoin-dev-bounces at lists.linuxfoundation.org] On Behalf Of Matt\n\u003e Corallo via bitcoin-dev\n\u003e Sent: Tuesday, 9 February, 2016 03:27\n\u003e To: Bitcoin Dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e Subject: [bitcoin-dev] On Hardforks in the Context of SegWit\n\u003e \n\u003e Hi all,\n\u003e \n\u003e I believe we, today, have a unique opportunity to begin to close the book on\n\u003e the short-term scaling debate.\n\u003e \n\u003e First a little background. The scaling debate that has been gripping the\n\u003e Bitcoin community for the past half year has taken an interesting turn in\n\u003e 2016. Until recently, there have been two distinct camps - one proposing a\n\u003e significant change to the consensus-enforced block size limit to allow for\n\u003e more on-blockchain transactions and the other opposing such a change,\n\u003e suggesting instead that scaling be obtained by adding more flexible systems\n\u003e on top of the blockchain. At this point, however, the entire Bitcoin\n\u003e community seems to have unified around a single vision - roughly 2MB of\n\u003e transactions per block, whether via Segregated Witness or via a hard fork,\n\u003e is something that can be both technically supported and which adds more\n\u003e headroom before second-layer technologies must be in place. Additionally, it\n\u003e seems that the vast majority of the community agrees that segregated witness\n\u003e should be implemented in the near future and that hard forks will be a\n\u003e necessity at some point, and I don't believe it should be controversial\n\u003e that, as we have never done a hard fork before, gaining experience by\n\u003e working towards a hard fork now is a good idea.\n\u003e \n\u003e With the apparent agreement in the community, it is incredibly disheartening\n\u003e that there is still so much strife, creating a toxic environment in which\n\u003e developers are not able to work, companies are worried about their future\n\u003e ability to easily move Bitcoins, and investors are losing confidence. The\n\u003e way I see it, this broad unification of visions across all parts of the\n\u003e community places the burden of selecting the most technically-sound way to\n\u003e achieve that vision squarely on the development community.\n\u003e \n\u003e Sadly, the strife is furthered by the huge risks involved in a hard fork in\n\u003e the presence of strife, creating a toxic cycle which prevents a safe hard\n\u003e fork. While there has been talk of doing an \"emergency hardfork\" as an\n\u003e option, and while I do believe this is possible, it is not something that\n\u003e will be easy, especially for something as controversial as rising fees.\n\u003e Given that we have never done a hard fork before, being very careful and\n\u003e deliberate in doing so is critical, and the technical community working\n\u003e together to plan for all of the things that might go wrong is key to not\n\u003e destroying significant value.\n\u003e \n\u003e As such, I'd like to ask everyone involved to take this opportunity to\n\u003e \"reset\", forgive past aggressions, and return the technical debates to\n\u003e technical forums (ie here, IRC, etc).\n\u003e \n\u003e As what a hard fork should look like in the context of segwit has never\n\u003e (!) been discussed in any serious sense, I'd like to kick off such a\n\u003e discussion with a (somewhat) specific proposal.\n\u003e \n\u003e First some design notes:\n\u003e * I think a key design feature should be taking this opportunity to add\n\u003e small increases in decentralization pressure, where possible.\n\u003e * Due to the several non-linear validation time issues in transaction\n\u003e validation which are fixed by SegWit's signature-hashing changes, I strongly\n\u003e believe any hard fork proposal which changes the block size should rely on\n\u003e SegWit's existence.\n\u003e * As with any hard fork proposal, its easy to end up pulling in hundreds of\n\u003e small fixes for any number of protocol annoyances. In order to avoid doing\n\u003e this, we should try hard to stick with a few simple changes.\n\u003e \n\u003e Here is a proposed outline (to activate only after SegWit and with the\n\u003e currently-proposed version of SegWit):\n\u003e \n\u003e 1) The segregated witness discount is changed from 75% to 50%. The block\n\u003e size limit (ie transactions + witness/2) is set to 1.5MB. This gives a\n\u003e maximum block size of 3MB and a \"network-upgraded\" block size of roughly\n\u003e 2.1MB. This still significantly discounts script data which is kept out of\n\u003e the UTXO set, while keeping the maximum-sized block limited.\n\u003e \n\u003e 2) In order to prevent significant blowups in the cost to validate\n\u003e pessimistic blocks, we must place additional limits on the size of many\n\u003e non-segwit transactions. scriptPubKeys are now limited to 100 bytes in size\n\u003e and may not contain OP_CODESEPARATOR, scriptSigs must be push-only (ie no\n\u003e non-push opcodes), and transactions are only allowed to contain up to 20\n\u003e non-segwit inputs. Together these limits limit total-bytes-hashed in block\n\u003e validation to under 200MB without any possibility of making existing outputs\n\u003e unspendable and without adding additional per-block limits which make\n\u003e transaction-selection-for-mining difficult in the face of attacks or\n\u003e non-standard transactions. Though 200MB of hashing (roughly 2 seconds of\n\u003e hash-time on my high-end\n\u003e workstation) is pretty strongly centralizing, limiting transactions to fewer\n\u003e than 20 inputs seems arbitrarily low.\n\u003e \n\u003e Along similar lines, we may wish to switch MAX_BLOCK_SIGOPS from\n\u003e 1-per-50-bytes across the entire block to a per-transaction limit which is\n\u003e slightly looser (though not too much looser - even with libsecp256k1\n\u003e 1-per-50-bytes represents 2 seconds of single-threaded validation in just\n\u003e sigops on my high-end workstation).\n\u003e \n\u003e 3) Move SegWit's generic commitments from an OP_RETURN output to a second\n\u003e branch in the merkle tree. Depending on the timeline this may be something\n\u003e to skip - once there is tooling for dealing with the extra OP_RETURN output\n\u003e as a generic commitment, the small efficiency gain for applications checking\n\u003e the witness of only one transaction or checking a non-segwit commitment may\n\u003e not be worth it.\n\u003e \n\u003e 4) Instead of requiring the first four bytes of the previous block hash\n\u003e field be 0s, we allow them to contain any value. This allows Bitcoin mining\n\u003e hardware to reduce the required logic, making it easier to produce\n\u003e competitive hardware [1].\n\u003e \n\u003e I'll deliberately leave discussion of activation method out of this\n\u003e proposal. Both jl2012 and Luke-Jr recently begun some discussions about\n\u003e methods for activation on this list, and I'd love to see those continue.\n\u003e If folks think a hard fork should go ahead without SPV clients having a say,\n\u003e we could table #4, or activate #4 a year or two after 1-3 activate.\n\u003e \n\u003e \n\u003e [1] Simpler here may not be entirely true. There is potential for\n\u003e optimization if you brute force the SHA256 midstate, but if nothing else,\n\u003e this will prevent there being a strong incentive to use the version field as\n\u003e nonce space. This may need more investigation, as we may wish to just set\n\u003e the minimum difficulty higher so that we can add more than 4 nonce-bytes.\n\u003e \n\u003e \n\u003e \n\u003e \n\u003e Obviously we cannot reasonably move forward with a hard fork as long as the\n\u003e contention in the community continues. Still, I'm confident continuing to\n\u003e work towards SegWit as a 2MB-ish soft-fork in the short term with some plans\n\u003e on what a hard fork should look like if we can form broad consensus can go a\n\u003e long way to resolving much of the contention we've seen.\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\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\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 841 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160208/3e8cf754/attachment.sig\u003e",
"sig": "e3d5790008f8e9cb725222af63a46914e57b5a5fa4a87d057016600a3a86c85681454b10c6d5bb7811e898859881338cd98f85a79ca65ed37ca4c8e839433671"
}