public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Kalle Rosenbaum <kalle@rosenbaum•se>
To: Велеслав <veleslav.bips@protonmail•com>,
	bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP Proposal] Nym Enrolment Transaction Template
Date: Mon, 8 Oct 2018 20:59:00 +0200	[thread overview]
Message-ID: <CAPswA9xJgkXgxX9gPFa8BiFWqJrwrnMyhk4VryAh2-fBz9xfow@mail.gmail.com> (raw)
In-Reply-To: <QFg83njQkTWwnSLd_GxcmmHaD4TmocERn8RScBz0_cEjZmnAAsrtmpQsv-kjap7Nyf0wHZndH83gVKJ8ihkvI-cZF84fKqZD781SpLFYhXo=@protonmail.com>

[-- Attachment #1: Type: text/plain, Size: 2294 bytes --]

Hi Велеслав,

I won't comment on the usability of/need for this system, but I have a few
random comments and questions:

Why demand exactly one input? This will probably cause problems for wallets
with many small value UTXOs and no big.

Why demand exactly type p2wpkh on input? Why limit at all?

32-byte-nym_public_key is actually 33 bytes, no? Compressed pubkeys are 33
bytes.

Why verify "SIZE 32 EQUALVERIFY" on output 2? It puts a ceiling on the
entropy, but no floor, so it seems useless.

Why require segwit version 0 change output? This seems like an unnecessary
limitation.

It's not clear to me what's IsStandard rules and what's nym protocol rules
in the specification section. I interpret the specification to specify
IsStandard rules, but the section also mentions stuff not relevant to that,
for example how the nym signature is constructed and what the opreturn data
consists of. You should make the distinction more clear.

I couldn't find info on what 1-byte-nym_version and 1-byte-nym_use are and
how they are used. But it might not belong in the BIP if it only should
describe IsStandard policies?

Regards,
Kalle

Sent from my Sinclair ZX81

Den sön 7 okt. 2018 05:57Велеслав via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> skrev:

> Hello list,
>
> I would like to propose a draft BIP that takes the next available
> transaction version number and defines a new transaction template. This
> proposal does not have any consensus changes, and is purely for the
> application layer of Bitcoin. The new transaction template defines a
> special transaction structure that can be used as a cryptographic pseudonym.
>
> I hope the community will find this proposal useful and will find time to
> give it careful review.
>
> Here is the first BIP within our project
> https://github.com/veleslavs/bips/blob/bip_nym_tx/bip-nym_tx.mediawiki
>
> I would like to thank the entire team that has supported me in creating
> this proposal.
>
> С наилучшими пожеланиями,
> Велеслав
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 7899 bytes --]

      reply	other threads:[~2018-10-08 18:59 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-07  3:30 Велеслав
2018-10-08 18:59 ` Kalle Rosenbaum [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPswA9xJgkXgxX9gPFa8BiFWqJrwrnMyhk4VryAh2-fBz9xfow@mail.gmail.com \
    --to=kalle@rosenbaum$(echo .)se \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=veleslav.bips@protonmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox