📅 Original date posted:2015-09-29
📝 Original message:Mike,
Insults were not really my intention. Let's set aside our differences regarding SPV security and assume you understand the different implications for soft forks and hard forks.
Other than the fact that doing this as a soft fork requires an extra OP_DROP, how would doing this as a hard fork make any difference to SPV clients? If, as others have suggested, all clients warn the user on unrecognized nVersion and make unknown noops nonstandard, would this satisfy your concerns? The logic seems pretty straightforward.
- Eric
On September 28, 2015 5:54:33 AM PDT, Mike Hearn <hearn at vinumeris.com> wrote:
>>
>> we have NO hard fork mechanism in place that isn't highly prone to
>> systemic consensus failure.
>>
>
>Just use an opcode that isn't currently defined. Done. What about that
>mechanism is prone to failure?
>
>Re: coma. No need for insults. Please read my article and address the
>points raised there, which, by the way, do not include any mention of
>SPV
>wallets. Although your belief that SPV wallets are "inherently
>insecure"
>seems needlessly trollish - I certainly would disagree, but it's a
>different debate.
--
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/20150928/f4f3138f/attachment-0001.html>;
Eric Lombrozo [ARCHIVE] /
npub1az…t2krq
2023-06-07 17:41:29
in reply to nevent1q…wrfs
Author Public Key
npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krqPublished at
2023-06-07 17:41:29Event JSON
{
"id": "efa588e9860d183030ae1aba2079ba777ab266eaa81cac2e340098d46b20c072",
"pubkey": "e899768d254f3537af7e26455968583632d0ab0bd4c780445eacfa087ac80d8f",
"created_at": 1686159689,
"kind": 1,
"tags": [
[
"e",
"f5bb1bf208994917ac3ec4154383520df2a8573df815c54d28bae4e41ef024c8",
"",
"root"
],
[
"e",
"eda6a425859fe9dd34ba4bc05d4c96eae03926da970add2ccd9db4564542a80e",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2015-09-29\n📝 Original message:Mike,\n\nInsults were not really my intention. Let's set aside our differences regarding SPV security and assume you understand the different implications for soft forks and hard forks.\n\nOther than the fact that doing this as a soft fork requires an extra OP_DROP, how would doing this as a hard fork make any difference to SPV clients? If, as others have suggested, all clients warn the user on unrecognized nVersion and make unknown noops nonstandard, would this satisfy your concerns? The logic seems pretty straightforward.\n\n- Eric\n\nOn September 28, 2015 5:54:33 AM PDT, Mike Hearn \u003chearn at vinumeris.com\u003e wrote:\n\u003e\u003e\n\u003e\u003e we have NO hard fork mechanism in place that isn't highly prone to\n\u003e\u003e systemic consensus failure.\n\u003e\u003e\n\u003e\n\u003eJust use an opcode that isn't currently defined. Done. What about that\n\u003emechanism is prone to failure?\n\u003e\n\u003eRe: coma. No need for insults. Please read my article and address the\n\u003epoints raised there, which, by the way, do not include any mention of\n\u003eSPV\n\u003ewallets. Although your belief that SPV wallets are \"inherently\n\u003einsecure\"\n\u003eseems needlessly trollish - I certainly would disagree, but it's a\n\u003edifferent debate.\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/20150928/f4f3138f/attachment-0001.html\u003e",
"sig": "700c4345ff4421e86a296360be1c19b7bf2386df4dd5bea750144b1159d49ab2b917f98e7873fb51d9e4206227adbeb716a5592b3f387c1f6308ebb676ac8658"
}