📅 Original date posted:2018-10-08
📝 Original message: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 at 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 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/20181008/0d51220c/attachment.html>;
Kalle Rosenbaum [ARCHIVE] /
npub1uw…55zf7
2023-06-07 18:14:58
in reply to nevent1q…y0h6
Author Public Key
npub1uwweecasakwtk96j3vjmkjenhnhyv4rku382txq0kmexjwuh4w2st55zf7Published at
2023-06-07 18:14:58Event JSON
{
"id": "0dc0679cf7e4ab5a3fb91c44090125693ab875dc39c87599a08e90946356f2bd",
"pubkey": "e39d9ce3b0ed9cbb17528b25bb4b33bcee465476e44ea5980fb6f2693b97ab95",
"created_at": 1686161698,
"kind": 1,
"tags": [
[
"e",
"9e17881f06eeb37a7ca3b84920606962fe1f94ffb0ac5ebafe40e8d7de01fffe",
"",
"root"
],
[
"e",
"6cf4619f6c06480cb944ea65b2e3173f69c6bd5f81c44c77eac59ae12b006c7d",
"",
"reply"
],
[
"p",
"e6a505680dd7d6efd4f373b182a6f4ad9f3a6663b2049b8215564c242e6433e7"
]
],
"content": "📅 Original date posted:2018-10-08\n📝 Original message:Hi Велеслав,\n\nI won't comment on the usability of/need for this system, but I have a few\nrandom comments and questions:\n\nWhy demand exactly one input? This will probably cause problems for wallets\nwith many small value UTXOs and no big.\n\nWhy demand exactly type p2wpkh on input? Why limit at all?\n\n32-byte-nym_public_key is actually 33 bytes, no? Compressed pubkeys are 33\nbytes.\n\nWhy verify \"SIZE 32 EQUALVERIFY\" on output 2? It puts a ceiling on the\nentropy, but no floor, so it seems useless.\n\nWhy require segwit version 0 change output? This seems like an unnecessary\nlimitation.\n\nIt's not clear to me what's IsStandard rules and what's nym protocol rules\nin the specification section. I interpret the specification to specify\nIsStandard rules, but the section also mentions stuff not relevant to that,\nfor example how the nym signature is constructed and what the opreturn data\nconsists of. You should make the distinction more clear.\n\nI couldn't find info on what 1-byte-nym_version and 1-byte-nym_use are and\nhow they are used. But it might not belong in the BIP if it only should\ndescribe IsStandard policies?\n\nRegards,\nKalle\n\nSent from my Sinclair ZX81\n\nDen sön 7 okt. 2018 05:57Велеслав via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e skrev:\n\n\u003e Hello list,\n\u003e\n\u003e I would like to propose a draft BIP that takes the next available\n\u003e transaction version number and defines a new transaction template. This\n\u003e proposal does not have any consensus changes, and is purely for the\n\u003e application layer of Bitcoin. The new transaction template defines a\n\u003e special transaction structure that can be used as a cryptographic pseudonym.\n\u003e\n\u003e I hope the community will find this proposal useful and will find time to\n\u003e give it careful review.\n\u003e\n\u003e Here is the first BIP within our project\n\u003e https://github.com/veleslavs/bips/blob/bip_nym_tx/bip-nym_tx.mediawiki\n\u003e\n\u003e I would like to thank the entire team that has supported me in creating\n\u003e this proposal.\n\u003e\n\u003e С наилучшими пожеланиями,\n\u003e Велеслав\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181008/0d51220c/attachment.html\u003e",
"sig": "6e03ef7f5c5e94f22328e3c706513b26b5b64f68506c3ed10634b26bab919d05116d014ba81551565804ed1ef249f644fc9d1689a48ed6ff7c44f4c527edd644"
}