📅 Original date posted:2015-12-12
📝 Original message:A segwit supporting server would be required to support relaying segwit
transactions, although a non-segwit server could at least inform a wallet
of segwit txns observed, even if it doesn't relay all information necessary
to validate.
Non segwit servers and wallets would continue operations as if nothing had
occurred.
If this means essentially that a soft fork deployment of SegWit will
require SPV wallet servers to change their logic (or risk not being able to
send payments) then it does seem to me that a hard fork to deploy this non
controversial change is not only cleaner (on the data structure side) but
safer in terms of the potential to affect the user experience.
— Regards,
On Sat, Dec 12, 2015 at 1:43 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Fri, Dec 11, 2015 at 11:18 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
>
>> This is basically what I meant by
>>
>> struct hashRootStruct
>> {
>> uint256 hashMerkleRoot;
>> uint256 hashWitnessesRoot;
>> uint256 hashextendedHeader;
>> }
>>
>> but my design doesn't calculate other_root as it appears in your tree (is
>> not necessary).
>>
>> It is necessary to maintain compatibility with SPV nodes/wallets.
>
> Any code that just checks merkle paths up into the block header would have
> to change if the structure of the merkle tree changed to be three-headed at
> the top.
>
> If it remains a binary tree, then it doesn't need to change at all-- the
> code that produces the merkle paths will just send a path that is one step
> deeper.
>
> Plus, it's just weird to have a merkle tree that isn't a binary tree.....
>
> --
> --
> Gavin Andresen
>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151212/68adbb6a/attachment.html>;
Mark Friedenbach [ARCHIVE] /
npub1r3…48d0u
2023-06-07 17:45:46
in reply to nevent1q…vasr
Author Public Key
npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0uPublished at
2023-06-07 17:45:46Event JSON
{
"id": "74fd8d262049c5466706ca85abd9c592cf1b81f9eff3e375095ffbf4d482307c",
"pubkey": "1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069",
"created_at": 1686159946,
"kind": 1,
"tags": [
[
"e",
"558b0da1f3869961bbef0556878e1dd6b9ae37e86128bc130bab17f5332c918d",
"",
"root"
],
[
"e",
"91bae02a380ae80371efe8bcc6b57d13b76791797215eb634d88ab1db13f220d",
"",
"reply"
],
[
"p",
"5e443cb0b6d106eff3f575afdde950b050d870d92087a757730de6ffb515d46f"
]
],
"content": "📅 Original date posted:2015-12-12\n📝 Original message:A segwit supporting server would be required to support relaying segwit\ntransactions, although a non-segwit server could at least inform a wallet\nof segwit txns observed, even if it doesn't relay all information necessary\nto validate.\n\nNon segwit servers and wallets would continue operations as if nothing had\noccurred.\nIf this means essentially that a soft fork deployment of SegWit will\nrequire SPV wallet servers to change their logic (or risk not being able to\nsend payments) then it does seem to me that a hard fork to deploy this non\ncontroversial change is not only cleaner (on the data structure side) but\nsafer in terms of the potential to affect the user experience.\n\n\n— Regards,\n\n\nOn Sat, Dec 12, 2015 at 1:43 AM, Gavin Andresen via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Fri, Dec 11, 2015 at 11:18 AM, Jorge Timón \u003cjtimon at jtimon.cc\u003e wrote:\n\u003e\n\u003e\u003e This is basically what I meant by\n\u003e\u003e\n\u003e\u003e struct hashRootStruct\n\u003e\u003e {\n\u003e\u003e uint256 hashMerkleRoot;\n\u003e\u003e uint256 hashWitnessesRoot;\n\u003e\u003e uint256 hashextendedHeader;\n\u003e\u003e }\n\u003e\u003e\n\u003e\u003e but my design doesn't calculate other_root as it appears in your tree (is\n\u003e\u003e not necessary).\n\u003e\u003e\n\u003e\u003e It is necessary to maintain compatibility with SPV nodes/wallets.\n\u003e\n\u003e Any code that just checks merkle paths up into the block header would have\n\u003e to change if the structure of the merkle tree changed to be three-headed at\n\u003e the top.\n\u003e\n\u003e If it remains a binary tree, then it doesn't need to change at all-- the\n\u003e code that produces the merkle paths will just send a path that is one step\n\u003e deeper.\n\u003e\n\u003e Plus, it's just weird to have a merkle tree that isn't a binary tree.....\n\u003e\n\u003e --\n\u003e --\n\u003e Gavin Andresen\n\u003e\n\n\n_______________________________________________\nbitcoin-dev mailing list\nbitcoin-dev at lists.linuxfoundation.org\nhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151212/68adbb6a/attachment.html\u003e",
"sig": "ef86ff7395c3b9667c47870638d51df9849d5b5f52a529425f7b7ad0f56d455a7522d1218daf18be48e8e0e01bfc5080f7fc8fdf007e0836d1dc91236ed8bd67"
}