Hampus Sjöberg [ARCHIVE] on Nostr: 📅 Original date posted:2016-12-04 📝 Original message:> Also how about making ...
đź“… Original date posted:2016-12-04
đź“ť Original message:> Also how about making timestamp 8 bytes? 2106 is coming up soon :)
AFAICT this was fixed in this commit:
https://github.com/jl2012/bitcoin/commit/fa80b48bb4237b110ceffe11edc14c8130672cd2#diff-499d7ee7998a27095063ed7b4dd7c119R200
2016-12-04 21:00 GMT+01:00 adiabat via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> Interesting stuff! I have some comments, mostly about the header.
>
> The header of forcenet is mostly described in Luke’s BIP, but I have made
>> some amendments as I implemented it. The format is (size in parentheses;
>> little endian):
>>
>> Height (4), BIP9 signalling field (4), hardfork signalling field (3),
>> merge-mining hard fork signalling field (1), prev hash (32), timestamp (4),
>> nonce1 (4), nonce2 (4), nonce3 (compactSize + variable), Hash TMR (32),
>> Hash WMR (32), total tx size (8) , total tx weight (8), total sigops (8),
>> number of tx (4), merkle branches leading to header C (compactSize + 32 bit
>> hashes)
>>
>
> First, I'd really rather not have variable length fields in the header.
> It's so much nicer to just have a fixed size.
>
> Is having both TMR and WMR really needed? As segwit would be required
> with this header type, and the WMR covers a superset of the data that the
> TMR does, couldn't you get rid of the TMR? The only disadvantage I can see
> is that light clients may want a merkle proof of a transaction without
> having to download the witnesses for that transaction. This seems pretty
> minor, especially as once they're convinced of block inclusion they can
> discard the witness data, and also the tradeoff is that light clients will
> have to download and store and extra 32 bytes per block, likely offsetting
> any savings from omitting witness data.
>
> The other question is that there's a bit that's redundant: height is also
> committed to in the coinbase tx via bip 34 (speaking of which, if there's a
> hard-fork, how about reverting bip 34 and committing to the height with
> coinbase tx nlocktime instead?)
>
> Total size / weight / number of txs also feels pretty redundant. Not a
> lot of space but it's hard to come up with a use for them. Number of tx
> could be useful if you want to send all the leaves of a merkle tree, but
> you could also do that by committing to the depth of the merkle tree in the
> header, which is 1 byte.
>
> Also how about making timestamp 8 bytes? 2106 is coming up soon :)
>
> Maybe this is too nit-picky; maybe it's better to put lots of stuff in for
> testing the forcenet and then take out all the stuff that wasn't used or
> had issues as it progresses.
>
> Thanks and looking forward to trying out forcenet!
>
> -Tadge
>
> _______________________________________________
> 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/20161204/77223c7c/attachment.html>;
đź“ť Original message:> Also how about making timestamp 8 bytes? 2106 is coming up soon :)
AFAICT this was fixed in this commit:
https://github.com/jl2012/bitcoin/commit/fa80b48bb4237b110ceffe11edc14c8130672cd2#diff-499d7ee7998a27095063ed7b4dd7c119R200
2016-12-04 21:00 GMT+01:00 adiabat via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> Interesting stuff! I have some comments, mostly about the header.
>
> The header of forcenet is mostly described in Luke’s BIP, but I have made
>> some amendments as I implemented it. The format is (size in parentheses;
>> little endian):
>>
>> Height (4), BIP9 signalling field (4), hardfork signalling field (3),
>> merge-mining hard fork signalling field (1), prev hash (32), timestamp (4),
>> nonce1 (4), nonce2 (4), nonce3 (compactSize + variable), Hash TMR (32),
>> Hash WMR (32), total tx size (8) , total tx weight (8), total sigops (8),
>> number of tx (4), merkle branches leading to header C (compactSize + 32 bit
>> hashes)
>>
>
> First, I'd really rather not have variable length fields in the header.
> It's so much nicer to just have a fixed size.
>
> Is having both TMR and WMR really needed? As segwit would be required
> with this header type, and the WMR covers a superset of the data that the
> TMR does, couldn't you get rid of the TMR? The only disadvantage I can see
> is that light clients may want a merkle proof of a transaction without
> having to download the witnesses for that transaction. This seems pretty
> minor, especially as once they're convinced of block inclusion they can
> discard the witness data, and also the tradeoff is that light clients will
> have to download and store and extra 32 bytes per block, likely offsetting
> any savings from omitting witness data.
>
> The other question is that there's a bit that's redundant: height is also
> committed to in the coinbase tx via bip 34 (speaking of which, if there's a
> hard-fork, how about reverting bip 34 and committing to the height with
> coinbase tx nlocktime instead?)
>
> Total size / weight / number of txs also feels pretty redundant. Not a
> lot of space but it's hard to come up with a use for them. Number of tx
> could be useful if you want to send all the leaves of a merkle tree, but
> you could also do that by committing to the depth of the merkle tree in the
> header, which is 1 byte.
>
> Also how about making timestamp 8 bytes? 2106 is coming up soon :)
>
> Maybe this is too nit-picky; maybe it's better to put lots of stuff in for
> testing the forcenet and then take out all the stuff that wasn't used or
> had issues as it progresses.
>
> Thanks and looking forward to trying out forcenet!
>
> -Tadge
>
> _______________________________________________
> 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/20161204/77223c7c/attachment.html>;