digitsu at gmail.com [ARCHIVE] on Nostr: 📅 Original date posted:2015-12-12 📝 Original message:If this means essentially ...

📅 Original date posted:2015-12-12
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151211/63cf45aa/attachment.html>;