What is Nostr?
Gavin Andresen [ARCHIVE] /
npub1s4lā€¦44kw
2023-06-07 17:45:44
in reply to nevent1qā€¦96fc

Gavin Andresen [ARCHIVE] on Nostr: šŸ“… Original date posted:2015-12-09 šŸ“ Original message:On Wed, Dec 9, 2015 at ...

šŸ“… Original date posted:2015-12-09
šŸ“ Original message:On Wed, Dec 9, 2015 at 3:03 AM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I think it would be logical to do as part of a hardfork that moved
> commitments generally; e.g. a better position for merged mining (such
> a hardfork was suggested in 2010 as something that could be done if
> merged mining was used), room for commitments to additional block
> back-references for compact SPV proofs, and/or UTXO set commitments.
> Part of the reason to not do it now is that the requirements for the
> other things that would be there are not yet well defined. For these
> other applications, the additional overhead is actually fairly
> meaningful; unlike the fraud proofs.
>

So just design ahead for those future uses. Make the merkle tree:


root_in_block_header
/ \
tx_data_root other_root
/ \
segwitness_root reserved_for_future_use_root

... where reserved_for_future_use is zero until some future block version
(or perhaps better, is just chosen arbitrarily by the miner and sent along
with the block data until some future block version).

That would minimize future disruption of any code that produced or consumed
merkle proofs of the transaction data or segwitness data, especially if the
reserved_for_future_use_root is allowed to be any arbitrary 256-bit value
and not a constant that would get hard-coded into segwitness-proof-checking
code.


--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/89ff9b06/attachment.html>;
Author Public Key
npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw