* [bitcoin-dev] [BIP Proposal] Nym Enrolment Transaction Template
@ 2018-10-07 3:30 Велеслав
2018-10-08 18:59 ` Kalle Rosenbaum
0 siblings, 1 reply; 2+ messages in thread
From: Велеслав @ 2018-10-07 3:30 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 730 bytes --]
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.
С наилучшими пожеланиями,
Велеслав
[-- Attachment #2: Type: text/html, Size: 7185 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [bitcoin-dev] [BIP Proposal] Nym Enrolment Transaction Template
2018-10-07 3:30 [bitcoin-dev] [BIP Proposal] Nym Enrolment Transaction Template Велеслав
@ 2018-10-08 18:59 ` Kalle Rosenbaum
0 siblings, 0 replies; 2+ messages in thread
From: Kalle Rosenbaum @ 2018-10-08 18:59 UTC (permalink / raw)
To: Велеслав, bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2018-10-08 18:59 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-07 3:30 [bitcoin-dev] [BIP Proposal] Nym Enrolment Transaction Template Велеслав
2018-10-08 18:59 ` Kalle Rosenbaum
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox