📅 Original date posted:2015-09-16
📝 Original message:The exact numbers (95% vs. 75% etc) don't need to be completely specified to start working on an implementation. What really matters for now is defining the states and trigger mechanisms. I'd rather we not argue over the optimal values for supermajority requirement at this point.
On September 16, 2015 5:03:43 PM EDT, "Jorge Timón via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org> wrote:
>I understand your proposal, but I don't see what it accomplishes
>compared
>to applying the new rule from the start (in your own blocks) and wait
>for
>95% for consensus activation (which is my preference and it's much
>simpler
>to implement).
>What are the disadvantages of my approach? What are the advantages of
>yours?
>On Sep 16, 2015 4:57 PM, "Tier Nolan via bitcoin-dev" <
>bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>
>>
>> On Wed, Sep 16, 2015 at 9:54 PM, Jorge Timón <jtimon at jtimon.cc>
>wrote:
>>
>>>
>>> On Sep 16, 2015 4:49 PM, "Tier Nolan via bitcoin-dev" <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> > At 75%, if someone sets the bit, then they should be creating
>valid
>>> blocks (under the rule).
>>>
>>> You shouldn't rely on that, some may start applying the restrictions
>in
>>> their own blocks at 0% and others only at 90%. Until it becomes a
>consensus
>>> rule it is just part of the standard policy (and we shouldn't rely
>on nodes
>>> following the standard policy).
>>>
>>
>> It would be a consensus rule. If >75% of the blocks in the last 2016
>> window have the bit set, then reject all blocks that have the bit set
>and
>> fail to meet the rule.
>>
>>
>> _______________________________________________
>> 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
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150916/d29bd9ce/attachment.html>;
Eric Lombrozo [ARCHIVE] /
npub1az…t2krq
2023-06-07 19:40:07
in reply to nevent1q…s6f4
Author Public Key
npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krqPublished at
2023-06-07 19:40:07Event JSON
{
"id": "d7a695bf765776f09109b0e13990ffd36a2908643f51ca9a1e712c2f7ff4a0cd",
"pubkey": "e899768d254f3537af7e26455968583632d0ab0bd4c780445eacfa087ac80d8f",
"created_at": 1686159607,
"kind": 1,
"tags": [
[
"e",
"97970fd647e1ad99b763fefc14ff6c3da92992c59a8d85f2e5fe9ba87f5c9fb9",
"",
"root"
],
[
"e",
"f4d5994ebd08f53e93a286da34f644e3b0b7a58f9e8f1d4792daee81cbb03c0b",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2015-09-16\n📝 Original message:The exact numbers (95% vs. 75% etc) don't need to be completely specified to start working on an implementation. What really matters for now is defining the states and trigger mechanisms. I'd rather we not argue over the optimal values for supermajority requirement at this point.\n\nOn September 16, 2015 5:03:43 PM EDT, \"Jorge Timón via bitcoin-dev\" \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003eI understand your proposal, but I don't see what it accomplishes\n\u003ecompared\n\u003eto applying the new rule from the start (in your own blocks) and wait\n\u003efor\n\u003e95% for consensus activation (which is my preference and it's much\n\u003esimpler\n\u003eto implement).\n\u003eWhat are the disadvantages of my approach? What are the advantages of\n\u003eyours?\n\u003eOn Sep 16, 2015 4:57 PM, \"Tier Nolan via bitcoin-dev\" \u003c\n\u003ebitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On Wed, Sep 16, 2015 at 9:54 PM, Jorge Timón \u003cjtimon at jtimon.cc\u003e\n\u003ewrote:\n\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e On Sep 16, 2015 4:49 PM, \"Tier Nolan via bitcoin-dev\" \u003c\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e \u003e At 75%, if someone sets the bit, then they should be creating\n\u003evalid\n\u003e\u003e\u003e blocks (under the rule).\n\u003e\u003e\u003e\n\u003e\u003e\u003e You shouldn't rely on that, some may start applying the restrictions\n\u003ein\n\u003e\u003e\u003e their own blocks at 0% and others only at 90%. Until it becomes a\n\u003econsensus\n\u003e\u003e\u003e rule it is just part of the standard policy (and we shouldn't rely\n\u003eon nodes\n\u003e\u003e\u003e following the standard policy).\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\u003e It would be a consensus rule. If \u003e75% of the blocks in the last 2016\n\u003e\u003e window have the bit set, then reject all blocks that have the bit set\n\u003eand\n\u003e\u003e fail to meet the rule.\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\u003e\n\u003e\n\u003e\n\u003e------------------------------------------------------------------------\n\u003e\n\u003e_______________________________________________\n\u003ebitcoin-dev mailing list\n\u003ebitcoin-dev at lists.linuxfoundation.org\n\u003ehttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n-- \nSent from my Android device with K-9 Mail. Please excuse my brevity.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150916/d29bd9ce/attachment.html\u003e",
"sig": "dac8d454999120e22b4e7cbeb355680c10ab4a1ba9062fef5a6ecb1abe522883ad9566da842aa7ea7e559ebd7b3517d93679b1a1127d3e3c3574604eeb49ba70"
}