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@lists.linuxfoundation.org> wrote:
> On Fri, Dec 11, 2015 at 11:18 AM, Jorge Timón <jti...@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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
