<div>Hi,<br></div><div class="protonmail_signature_block protonmail_signature_block-empty"><div class="protonmail_signature_block-user protonmail_signature_block-empty"><div><br></div></div><div class="protonmail_signature_block-proton protonmail_signature_block-empty"><br></div></div><div><br></div><div> On June 25, 2018 12:47 PM, Tomas Susanka via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: <br></div><blockquote class="protonmail_quote" type="cite"><div style="font-family:
-moz-fixed; font-size: 12px;" wrap="true" class="moz-text-plain" lang="x-unicode"><pre wrap="">From my perspective those are exactly the points I have felt strongly
about. I still think "typed records" would be a better choice, but it's
something I'm willing to compromise on. As I'm looking at the draft, we
currently have 13 records and only 3 of them have keys... Matejcik was a
bit keener on this, so we'll try to discuss this more during the week
and we also look at the draft more carefully to see if we can come up
with some nit-picks.<br></pre></div></blockquote><div>So there are a few reasons for not using typed records. Firstly, it is less of a breaking change to retain the key-value map model. <br></div><div><br></div><div>Secondly, it is easier to enforce uniqueness for certain things. For example, in each input, we only want to have one redeemScript and one witnessScript. With a typed records set, we would have to say that only on record of each type is allowed, which means that combiners need to understand types and be able to partially parse the records. However with a key-value model, we can more generically say that every key-value pair must have a unique key which means that combiners do not need to know anything about types and just needs to enforce key uniqueness. Since the type is the only thing in the key for redeemScripts and witnessScripts, this uniqueness automatically applies to this, as well as for other key-value pairs.<br></div><div><br></div><div>Lastly, the typed records model does not save a lot of space in a transaction. Each record has at most one extra byte in the key-value model, with records that must also have keys having no space savings. The data inside each key-value pair far exceeds one byte, so on additional byte per key-value pair isn't all that big of a deal, IMO.<br></div><div><br></div><div>Andrew<br></div>