Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id ACF4A79E8 for ; Mon, 8 Oct 2018 18:59:14 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk1-f178.google.com (mail-qk1-f178.google.com [209.85.222.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D66BA6C5 for ; Mon, 8 Oct 2018 18:59:13 +0000 (UTC) Received: by mail-qk1-f178.google.com with SMTP id 12-v6so5844810qkj.10 for ; Mon, 08 Oct 2018 11:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rosenbaum-se.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=E0BgYTQl3zai++6ggGUOUVO1n7bUxmT10tw4h1HBGME=; b=rfiSRKhpkZAwQUPUJr1SvNycgzDf0JY2vyQHio6zN8rONrWOSDEeY6/hI881sIJp2b dm/+qK1ix/WYgAJtOYOHe8Avk4bxrv6CLzd+K6wCWRZt9XOq0oqeSceVtXjecAPhptAa JEqsk2FhfYM9DMpMpx/SGv09GX7PXjMpnkH6q2JAGCLDrixGsqJYld3Tmvd86YTBCceJ QIzCgjlybLfEixPceHOWGJUmAqhfIrMM867c5T7naV1oceUn8jjUffjgIBnpTslIExI0 ZBFA+tD0EV/pQn80eQNiAbX+sJgrGcCEfEoXw+Nr6wuOKDgmw29rBHnMn6tHA17GliUI kJiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=E0BgYTQl3zai++6ggGUOUVO1n7bUxmT10tw4h1HBGME=; b=S0kIq7BhuwBk0/tIjUMPM3cwYfj8Do/s67FSmJcNq3JXCv/sOgdSBpQpBNTf1TLBDt pOvB34UqxO2vk8yUh/hAwtGGtWnL6F5qnCWFjsixAIFUO3y96NAu417ZhnDR0iqmoIr/ HRog3tOVIlOpfHhgJMb47TiNz+TfjuCy5Vl5zksl9I9guXzWAUeGwEo1psHx23D9mX0G spRFCaHLCZd823GG4wuAkpUfejSGChs2RXD7enaeQHUXJw2TuDD0vTIa5QGSKf3dok3X tbY6U6u8bolnaAWmSygqnL0ymZpvWQuCIONvqk5eVohHJcLE8fUQsv//ga6ljIcsPyin Xm4A== X-Gm-Message-State: ABuFfojAOYo2sZZAdgfHC/dAfTZu1sbqosmM2RF8YkTuFQYUxITy/KCM AkKJaCjzT0+mgPiUXEph0yMUNz2ArFopC2R/JmXoSQ== X-Google-Smtp-Source: ACcGV60lvMbXqiInc/F4Ybiz1nzJw/cIOPD42EP9/9C5T7ziTZEhclMigYDsQP11d3R+T+PFQxU2bURnaeJf0WNdHMA= X-Received: by 2002:a37:bbc1:: with SMTP id l184-v6mr20129447qkf.111.1539025152701; Mon, 08 Oct 2018 11:59:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kalle Rosenbaum Date: Mon, 8 Oct 2018 20:59:00 +0200 Message-ID: To: =?UTF-8?B?0JLQtdC70LXRgdC70LDQsg==?= , bitcoin-dev Content-Type: multipart/alternative; boundary="0000000000008708930577bc37d4" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Mon, 08 Oct 2018 19:32:34 +0000 Subject: Re: [bitcoin-dev] [BIP Proposal] Nym Enrolment Transaction Template X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 18:59:14 -0000 --0000000000008708930577bc37d4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi =D0=92=D0=B5=D0=BB=D0=B5=D1=81=D0=BB=D0=B0=D0=B2, 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=C3=B6n 7 okt. 2018 05:57=D0=92=D0=B5=D0=BB=D0=B5=D1=81=D0=BB=D0=B0=D0= =B2 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 pseudon= ym. > > 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. > > =D0=A1 =D0=BD=D0=B0=D0=B8=D0=BB=D1=83=D1=87=D1=88=D0=B8=D0=BC=D0=B8 =D0= =BF=D0=BE=D0=B6=D0=B5=D0=BB=D0=B0=D0=BD=D0=B8=D1=8F=D0=BC=D0=B8, > =D0=92=D0=B5=D0=BB=D0=B5=D1=81=D0=BB=D0=B0=D0=B2 > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000008708930577bc37d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi =D0=92=D0=B5=D0=BB=D0=B5=D1=81=D0=BB=D0=B0=D0=B2,=C2= =A0

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

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

Why demand exactly type p2w= pkh on input? Why limit at all?=C2=A0

32-byte-nym_public_key is actually 33 bytes, no? Compressed p= ubkeys are 33 bytes.=C2=A0

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

Why require segwit version 0 change output= ? This seems like an unnecessary limitation.=C2=A0
<= br>
It's not clear to me what's IsStandard r= ules and what's nym protocol rules in the specification section. I inte= rpret the specification to specify IsStandard rules, but the section also m= entions stuff not relevant to that, for example how the nym signature is co= nstructed and what the opreturn data consists of. You should make the disti= nction more clear.=C2=A0

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?=C2= =A0

Regards,= =C2=A0
Kalle=C2=A0

Sent from my Sinclair ZX81
Den s=C3=B6n 7 okt. 2018 05:5= 7=D0=92=D0=B5=D0=BB=D0=B5=D1=81=D0=BB=D0=B0=D0=B2 via bitcoin-dev <bitcoin-dev@lists.linux= foundation.org> skrev:
Hello list,

I would like to pro= pose a=C2=A0draft BIP that takes the next available transaction version num= ber 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

I would like to thank th= e entire team that has supported me in creating this proposal.

=D0=A1 =D0=BD=D0=B0=D0=B8=D0=BB=D1=83=D1=87=D1= =88=D0=B8=D0=BC=D0=B8 =D0=BF=D0=BE=D0=B6=D0=B5=D0=BB=D0=B0=D0=BD=D0=B8=D1= =8F=D0=BC=D0=B8,
=D0=92=D0=B5=D0=BB=D0=B5=D1=81=D0=BB=D0= =B0=D0=B2


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--0000000000008708930577bc37d4--