Elichai Turkel [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2019-06-17 to 2019-08-09
💬 Posted a total of 3 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:20:16

- reply

📅 Original date posted:2019-08-09
📝 Original message:Hi,
I want to add to John Newbery's suggestion of using implicit even/odd only
public keys and tweaked public keys in taproot and suggest the following:
If everything is implicit then the only reason for the first byte of the
control block(`c[0]`) is the tapscript leaf version.
I suggest that this is moved to be the first OP_CODE of the tapscript
itself (i.e. OP_0/OP_1 etc.)
That way having the script *tells* you what does it mean without needing to
check the control block.
That way there's a separation between the tapscript+leaf version and the
control block being the merkle path to the script.
--
PGP: 5607C93B5F86650C
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190809/8b965583/attachment.html>

2023-06-07 18:18:43

- reply

📅 Original date posted:2019-06-17
📝 Original message:Thanks,
I just couldn't find where is the message sequence number comes from.
So if it's max 1GB and it's an incremental counter that cannot be reseted
without a rekeying than it's perfectly fine :).
Thanks for the answer!
On Mon, Jun 17, 2019 at 12:20 PM Jonas Schnelli <dev at jonasschnelli.ch>
wrote:
> Hi Elichai
>
> > About the nonce being 64bit. (rfc7539 changed it to 96bit, which djb
> later calls xchacha)
> >
> > You suggest that we use the "message sequence number" as the nonce for
> Chacha20, Is this number randomly generate or is this a counter?
> > And could it be reseted without rekeying?
>
> The in BIP324 (v2 message transport protocol) proposed AEAD,
> ChaCha20Poly1305 at Bitcoin [1], uses a „message sequence number“. There is
> no such thing as random nonce described in the BIP (hence the term
> „sequence number“). The message sequence number starts with 0 and the max
> traffic before a rekey must occur is 1GB. A nonce/key reuse is conceptually
> impossible (of course implementations could screw up at this point).
>
> Using XChaCha20 with the possibility of a random nonce could be done, but
> I don’t see a reason to use it in our case since the usage of a sequence
> number as nonce seems perfectly save.
>
> [1]
> https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52#chacha20-poly1305bitcoin-cipher-suite
>
--
PGP: 5607C93B5F86650C
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190617/d7cf1656/attachment-0001.html>

2023-06-07 18:18:42

- reply

📅 Original date posted:2019-06-16
📝 Original message:Hi everyone,
About the nonce being 64bit. (rfc7539 changed it to 96bit, which djb later
calls xchacha)
You suggest that we use the "message sequence number" as the nonce for
Chacha20, Is this number randomly generate or is this a counter?
And could it be reseted without rekeying?
If it is randomly generated then 64bit isn't secure enough. And we should
either move to the chacha20 from RFC7539 which has 96bit nonce and 32bit
counter or increment it manually every time.
If it's simply a counter then 64bit nonce should be fine :)
Thanks,
Elichai.
--
PGP: 5607C93B5F86650C
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190616/84c36142/attachment.html>

2023-06-07 18:18:42

- reply