path: root/24/0809f3eddf5549f4e31f75d59c81c8897a7338

Return-Path: <ali@notatether.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 81CD4C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 29 Aug 2022 15:46:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id C70A94086D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 29 Aug 2022 15:46:27 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org C70A94086D
Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key,
 unprotected) header.d=notatether.com header.i=@notatether.com
 header.a=rsa-sha256 header.s=protonmail header.b=VcrpWpqC
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_BTC_ID=0.499,
 PDS_BTC_MSGID=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=no autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 6aqUr9A9b_ST
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 29 Aug 2022 15:46:24 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 2A95C407D7
Received: from mail-4018.proton.ch (mail-4018.proton.ch [185.70.40.18])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 2A95C407D7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 29 Aug 2022 15:46:23 +0000 (UTC)
Date: Mon, 29 Aug 2022 15:46:09 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=notatether.com;
 s=protonmail; t=1661787979; x=1662047179;
 bh=KL6MIhO8jCG++nJvmZRsAptRGA7SZnJ7RbqFROZ33wU=;
 h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
 References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To:
 Feedback-ID:Message-ID;
 b=VcrpWpqCD9tnhrhiJV55/j8+eq8yeKjjjInDxyJS8uLUH1YaG4Bl5fxwLai2A3M+W
 jm4irE+9Cag2mIUKqcpOyWMp7Js5yr3O7zPWdzEUD3iCkdCOEImyn8TU6hMYF1KDvF
 AvqoXrUExUpub5QIhdCYb9k6NTuL4dFat9rsLdmDh9PedyjzK4icbzTI5QqlJoghWE
 uduYAQ7qh31gFoIXU0ghSps8F2mL79tTMpzgStPSHo9xeRNBVYsDs+BnpO6NfLY1mu
 2Q93Z4il2xglN1r6f7NnuGFEoigJ27K4faAmHyxl+GWs+T3ICnWhSHcVI/mAShaiQ8
 9U9RycyYWdAUA==
To: craigraw@gmail.com
From: Ali Sherief <ali@notatether.com>
Reply-To: Ali Sherief <ali@notatether.com>
Message-ID: <20220829154603.fec7mlm526vdfo2i@artanis>
In-Reply-To: <mailman.13106.1661772392.956.bitcoin-dev@lists.linuxfoundation.org>
References: <mailman.13106.1661772392.956.bitcoin-dev@lists.linuxfoundation.org>
Feedback-ID: 34210769:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Mon, 29 Aug 2022 16:12:05 +0000
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP Proposal: Wallet Labels Export Format
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Aug 2022 15:46:28 -0000

> I am attempting to achieve two goals with this proposal, primarily for th=
e
> benefit of wallet users:
>
> Goal #1. Transfer labels between different wallet implementations
> Goal #2. Manage labels in applications outside of Bitcoin wallets (such a=
s
> Excel)
>
> Much of the feedback so far has indicated the tension between these two
> goals - it may be that it is too difficult to achieve both, in which case
> Goal #1 is the most important. That said, I think further exploration is
> still necessary before abandoning Goal #2, because removing it would
> significantly reduce the value of this proposal and mean users need to re=
ly
> on application-specific workarounds.
In my opinion, it would be best if these two goals were split into two sepa=
rate BIPs where the BIP for Goal 2 requires Goal 1's BIP, gut Goal 1's BIP =
is independent. This is because wallet software and business spreadsheet pr=
ocesses have different and in some cases divergent needs.

A BIP shouldn't try to address too many things at once, that's why technolo=
gies like Segwit and Taproot were split into four or five BIPs each.

>  > Don't mandate the file extension... There is no way to enforce this on=
 a
> BIP level.
> I'm not quite sure what you mean here - for example BIP174, which is wide=
ly
> used, states "Binary PSBT files should use the .psbt file extension." Als=
o,
> this contradicts Goal #2 - Excel and Numbers register as handlers for .cs=
v,
> and so make it clear that the file is editable outside of a wallet.
BIP174's assignment is a specification but not a hard requirement, becase i=
f you have a file whose extension implies one type, but its MIME type (obta=
ined from inspecting the file contents) indicates another type, then the ex=
tension should be disregarded by the parser.

I am aware that business processes are mostly CSV file oriented so you can =
make a statement akin to BIP174 in the Goal 2 BIP, that expects the medium =
of exchange to be in files ending in .csv. I wouldn't mind if you require .=
csv file extension in a BIP for Goal 2. But such a statement is not appropr=
iate in the Goal 1 BIP which is only concerned with the wallet label format=
 itself.

> > ZIP does not have good performance or compression ratio
> Indeed, but it is very widely available. That said, gzip is supported
> widely too these days. Unfortunately, gzip does not offer encryption (see
> next answer).
>
> > ZIP is an archiving format, that happens to have its own compression
> format.
> I agree this is not ideal. My main reason for choosing ZIP was that it
> supports encryption. It seems to me that without considering encryption, =
an
> application must create label export files that allow privacy-sensitive
> wallet information to be readable in plain text. Being able to transfer
> labels without risking privacy is IMO valuable. I considered other
> encryption formats such as PGP, but they are much more niche and so again
> contradict Goal #2.
Both of these look like parts of the spec that should be in the Goal 2 BIP.=
 Because Goal 1, which is only concerned with wallet label importing, does =
not need to interact with compression or encryption.

I don't mind if you make Goal 2 BIP utilize ZIP compression with optional e=
ncryption, it's just that specifying this in the same place in the Goal 1 B=
IP stuff forces wallets to check for that stuff too to be compliant. It's i=
mportant to make compliance as easy as possible.

Regardless, I still believe that making the xpub the ZIP password is a bad =
design, because some wallets that are made from a random list of private ke=
ys do not have xpubs at all. If the purpose of a password is to make label =
sharing between two parties secure, then why not simply let them agree on a=
 password for their own use?

> > I don't see the benefit of encrypting addresses and labels together...
> additionally, the password you propose is insecure - anybody with access =
to
> the wallet can unlock it
> I'm not sure I understand your question, but both wallet addresses and
> wallet labels contain privacy-sensitive information that should be
> protected. Wrt to the password, there is actually a more fundamental
> problem with using the wallet xpub - there is no equivalent for multisig
> wallets. For this reason I'll remove that requirement in future iteration=
s.
Let me explain.

Before you partitioned the BIP into two goals, I was under the impression t=
hat wallets would have to read an encrypted export file, which seemed very =
overkill to me (for one, all wallets would now need to bundle a ZIP or AES =
dependency module with their program).

But now I see why a password and encryption would be desireable for Goal 2 =
BIP applications. Like I said though, Goal 1 BIP applications (i.e. wallets=
) do not need any of that.

> > Why the need for input and output formats? There is no difference betwe=
en
> them on the wallet level, because they are always identified with a txid
> and output index.
> The input refers to the txid and the input index (in the set of vin), so
> the difference is the context in which they are displayed. A wallet will
> not necessarily store the spent outputs for a funding transaction
> containing a UTXO coming into the wallet, but it will contain references =
to
> the inputs as part of that transaction.
>
> > Another important point is that practically nobody labels inputs or
> outputs
> To the contrary, UTXOs are very frequently labelled, as they link and
> reveal information when spent. Inputs are much less frequently labelled,
> but there is no particular reason to exclude them.
>
> > there is a net benefit for the addresses to be exported in ascending or=
der
> Indeed, but it makes achieving Goal #2 much more difficult for marginal
> benefit.
Fair enough.

> > It's better to mandate that they should always be double-quoted, since
> only wallets will generate label exports anyway.
> Rather I think it's better to mandate RFC4180 is followed, as per
> recommendations in other feedback.
I agree with this.

> > The importing code is too naive... it should utilize a dedicate item ty=
pe
> field that unambiguously identifies the item
> It's unclear to me what you mean here. As I've indicated it is currently
> possible to disambiguate between addresses/transactions/etc without the
> need for a 3rd column, but in any case the hash functions used ensure tha=
t
> labels will not be associated incorrectly. Even in the unlikely event of
> some future address type being indistinguishable from a txid, it will
> simply not match any txids in the wallet.
You already have a custom format proposed here, but this importer relies on=
 heuristics of the data like how long it is, what characters it has, and so=
 on. It is better for the importer to have the same kind of conditions.

You can make parsing vastly simpler by prefixing the items with some text. =
Similar to how we have "bitcoin:" for indicating a bitcoin address, you can=
 have "address:", "transaction:", "input:", and "output:" at the beginning =
of each entity.

This has a major advantage: You can add new formats in a backward-compatibl=
e way without breaking parsers, since the parsers never depended on the tex=
t heuristics in the first place, therefore you don't have to clutter the BI=
P(s) with even more test vectors for these cases. You won't even need a ver=
sion byte, since the only revision that will ever be made (that doesn't mod=
ify any existing format to preserve backward-compatibility) are adding new =
formats.

Take a look at your sample:

> > >   if reference length < 64
> > >     Set address label
> > >   else if reference length =3D=3D 64
> > >     Set transaction label
> > >   else if reference contains '<'
> > >     Set input label
> > >   else
> > >     Set output label

versus how mine would look:

> if reference.startsWith("address:")
>   Set address label
> else if reference.startsWith("transaction:")
>   Set transaction label
> else if reference.startsWith("input:")
>   Set input label
> else if reference.startsWith("output:")
>   Set output label
> # No else case: allows for future extensions

See how simpler it is to understand?

The truth is, a format has to be defined that developers find it easy to im=
plement. If the implementation is such that a developer could misunderstand=
 at a first glance, they will implement it wrongly, creating bugs.

Looking at your sample, a developer would think as such: "anything less tha=
n 64 chars is an address, anything 64 chars long is a transaction, anything=
 that contains a '<' is an input (and is also greater than 64 chars), and e=
verything else is an output (>64 chars and has no  '<')."

In light of all this, is it not much easier to simply introduce a prefix at=
 the beginning of each entity? It has a negligible space cost. The "else" c=
ase can be ommitted hypothetically (although that's not strictly necessary)=
, so developers can just add more "else if"'s when a BIP revision is made.

A good way to see if a reference implementation has a good design is by ask=
ing yourself the following question: Imagine you are committing your refere=
nce into Bitcoin Core. Based on the code quality, would a pull request for =
that be merged, or not?


So to summarize, I strongly suggest you do the following:
- Split the BIP into two, one defines the CSV format for label import/expor=
t between wallets, and the other defines workflows for distributing and sha=
ring label CSVs in a universal and safe way.
- Add prefixes before each entity, so in other words: "adddress:bc1q23456..=
.", "transaction:432abd874d...", "input:432abd874d...<DELIMITER>1", "output=
:432abd874d...<DELIMITER>1". Replace <DELIMITER> with any delimiter you wan=
t, it doesn't have to be consistent. This will make it much simpler to impl=
ement an importer, without applications doing any of the hacks that RHavar =
wrote about (IMO this is what people mean when they say that implementing a=
 CSV importer will be complex work).

- Ali

On Mon, Aug 29, 2022 at 11:26:32AM +0000, craigraw@gmail.com wrote:
> Thanks for your feedback @Ali.
>
>
> > it is important that a version byte is defined
> If Goal #2 is to be achieved it's difficult to mandate this, particularly
> if one requires bit flags to be set. Should an importing wallet fail to
> import if the version byte is not present, even if all the data is
> otherwise correct? Although it is difficult to know in advance how a form=
at
> may be extended, it is certainly possible to extend this format with
> additional types where the nature of hashes serve as unique identifiers
> (more on this below).
>
>  > Don't mandate the file extension... There is no way to enforce this on=
 a
> BIP level.
> I'm not quite sure what you mean here - for example BIP174, which is wide=
ly
> used, states "Binary PSBT files should use the .psbt file extension." Als=
o,
> this contradicts Goal #2 - Excel and Numbers register as handlers for .cs=
v,
> and so make it clear that the file is editable outside of a wallet.
>
> > ZIP does not have good performance or compression ratio
> Indeed, but it is very widely available. That said, gzip is supported
> widely too these days. Unfortunately, gzip does not offer encryption (see
> next answer).
>
> > ZIP is an archiving format, that happens to have its own compression
> format.
> I agree this is not ideal. My main reason for choosing ZIP was that it
> supports encryption. It seems to me that without considering encryption, =
an
> application must create label export files that allow privacy-sensitive
> wallet information to be readable in plain text. Being able to transfer
> labels without risking privacy is IMO valuable. I considered other
> encryption formats such as PGP, but they are much more niche and so again
> contradict Goal #2.
>
> > I don't see the benefit of encrypting addresses and labels together...
> additionally, the password you propose is insecure - anybody with access =
to
> the wallet can unlock it
> I'm not sure I understand your question, but both wallet addresses and
> wallet labels contain privacy-sensitive information that should be
> protected. Wrt to the password, there is actually a more fundamental
> problem with using the wallet xpub - there is no equivalent for multisig
> wallets. For this reason I'll remove that requirement in future iteration=
s.
>
> > Why the need for input and output formats? There is no difference betwe=
en
> them on the wallet level, because they are always identified with a txid
> and output index.
> The input refers to the txid and the input index (in the set of vin), so
> the difference is the context in which they are displayed. A wallet will
> not necessarily store the spent outputs for a funding transaction
> containing a UTXO coming into the wallet, but it will contain references =
to
> the inputs as part of that transaction.
>
> > Another important point is that practically nobody labels inputs or
> outputs
> To the contrary, UTXOs are very frequently labelled, as they link and
> reveal information when spent. Inputs are much less frequently labelled,
> but there is no particular reason to exclude them.
>
> > there is a net benefit for the addresses to be exported in ascending or=
der
> Indeed, but it makes achieving Goal #2 much more difficult for marginal
> benefit.
>
> > It's better to mandate that they should always be double-quoted, since
> only wallets will generate label exports anyway.
> Rather I think it's better to mandate RFC4180 is followed, as per
> recommendations in other feedback.
>
> > The importing code is too naive... it should utilize a dedicate item ty=
pe
> field that unambiguously identifies the item
> It's unclear to me what you mean here. As I've indicated it is currently
> possible to disambiguate between addresses/transactions/etc without the
> need for a 3rd column, but in any case the hash functions used ensure tha=
t
> labels will not be associated incorrectly. Even in the unlikely event of
> some future address type being indistinguishable from a txid, it will
> simply not match any txids in the wallet.
>
> Craig
>
>
>
> On Wed, Aug 24, 2022 at 9:10 PM Ali Sherief <ali@notatether.com> wrote:
>
> > Hi Craig,
> >
> > This a really good proposal. I studied your BIP and I have some feedbac=
k
> > on some parts of it.
> >
> > > The first line in the file is a header, and should be ignored on impo=
rt.
> >
> > From past experience and lessons, most notably BIP39, it is important t=
hat
> > a version byte is defined somewhere in case someone wants to extend it =
in
> > the future, currently there is no version byte which someone can increm=
ent
> > if somebody wants to extend it. In the unique case of CSV files, you sh=
ould
> > make the header line mandatory (I see you have already implied this, bu=
t
> > you should make it explicit in the BIP), but instead of a line with col=
umns
> > in it, I suggest instead of Reference,Label, you make the format like t=
his:
> >
> > BIP-wallet-labels,<version>
> >
> > Since there are two columns per record, this works out nicely. The firs=
t
> > column can be the name of the BIP - BIPxxxx where the x's are numbers, =
and
> > the second column can be an unsigned 32-bit integer (most significant 8
> > bits reserved for version, the remaining for flags, or perhaps the enti=
rety
> > for version - but I recommend leaving at least some bits for flags, eve=
n if
> > they all end up being just "reserved").
> >
> > You should make importing fail if the header line is not exactly as
> > specified - or appropriate, should you decide a different format for th=
e
> > header.
> >
> > > Files exported should use the <tt>.csv</tt> file extension.
> > Don't mandate the file extension (read below for why):
> >
> > > In order to reduce file size while retaining wide accessibility, the =
CSV
> > > file may be compressed using the ZIP file format, using the <tt>.zip<=
/tt>
> > > file extension.
> > I see three problems with this. The first is more important than the la=
ter
> > two because it makes them moot points, but I'll mention them anyway so =
you
> > get a background of the situation:
> > - The BIP is trying to specify in what file format the export format ca=
n
> > be written in onto the filesystem. There is no way to enforce this on a=
 BIP
> > level (besides, Unix operating systems don't even consider the file
> > extension, they use its mimetype). Also specifying this in the BIP will
> > prevent modular "Layer 2" protocols and schemes from encoding the Expor=
t
> > labels into another format - for example Base64 or with their own
> > compression algorithm.
> >
> > Now for the two "moot problems":
> > - ZIP does not have good performance or compression ratio, there are
> > better algorithms out there like gzip (which also happens to be more
> > ubiquitous; nearly all websites are serving HTML compressed with gzip
> > compression).
> > - ZIP is an archiving format, that happens to have its own compression
> > format. Archiving format parsers can have serious vulnerabilities in th=
eir
> > implementation that can allow malware to swipe private keys and passwor=
ds,
> > since the primary target for this BIP is wallets. For example, there wa=
s
> > Zip Slip[1] in 2018, which allows for remote code execution. So the mal=
ware
> > can even hide in memory until private keys or passwords are written to
> > memory, then send them accros the network. Assuming it's targeting a
> > specific wallet software it's not hard to carry out at all.
> >
> > There's two solutions for all this:
> > 1. The duck-tape solution: Use some compression algorithm like gzip
> > instead of ZIP archive format.
> > 2. The "throw it out and buy a new one" solution: Get rid of the option=
al
> > compression specs altogether, because users are responsible for supplyi=
ng
> > the export labels in the first place, so all the compression stuff is
> > redundant and should be left up to the user use if they desire to.
> >
> > I prefer the second solution because it hits the nail at the problem
> > directly instead of putting duck tape on it like the first one.
> >
> > > This <tt>.zip</tt> file may optionally be encrypted using either AES-=
128
> > or
> > > AES-256 encryption, which is supported by numerous applications inclu=
ding
> > > Winzip and 7-zip.
> > > The textual representation of the wallet's extended public key (as
> > defined
> > > by BIP32, with an <tt>xpub</tt> header) should be used as the passwor=
d.
> > Not specific to AES, but I don't see the benefit of encrypting addresse=
s
> > and labels together. Can you please elaborate why this would be desirea=
ble?
> >
> > Like I said though, it's better to leave it up to users to decide how t=
o
> > store their exports, since BIPs can't enforce that anyway (additionally=
,
> > the password you propose is insecure - anybody with access to the walle=
t
> > can unlock it, which is not desireable to some users who want their own
> > security).
> >
> > > * Transaction ID (<tt>txid</tt>)
> > > * Address
> > > * Input (rendered as <tt>txid<index</tt>)
> > > * Output (rendered as <tt>txid>index</tt> or <tt>txid:index</tt>)
> > Why the need for input and output formats? There is no difference betwe=
en
> > them on the wallet level, because they are always identified with a txi=
d
> > and output index. To distinguish between them and hence write them with=
 the
> > correct format would require a UTXO set and thus access to a full node,
> > otherwise the CSV cannot be verified to be completely well-formed.
> >
> > Another important point is that practically nobody labels inputs or
> > outputs because most people do not know that those things even exist, a=
nd
> > the rest don't bother to label them.
> >
> > But the biggest downside to including them is related to the problem of
> > information leaking which you make reference to here:
> > > In both cases, care must be taken when spending to avoid undesirable
> > leaks
> > > of private information.
> > A CSV dump that has inputs/outputs and addresses mixed together can inf=
er
> > the owner of all those items. In fact, A CVS label dump is basically a
> > personal information store so everything in it can be correlated as com=
ing
> > from the same wallet, so it's important that unnecessary types are kept=
 out
> > of the format. People are known to leave files lying around on their
> > computer that they don't need anymore, so these files can find their wa=
y
> > via telemetry to surveillence entities. While we can't specify what use=
rs
> > can do with their exports, we can control the information leak by
> > preventing certain types of items that we know most users will never us=
e
> > from being exported in the first place.
> >
> > > The order in which these records appear is not defined.
> > Again, since the primary use case for this BIP is wallets, which likely
> > use heirarchical derivation schemes like BIP44, there is a net benefit =
for
> > the addresses to be exported in ascending order of their `address_type`=
. It
> > means that wallets can import them in O(n) time as opposed to O(n^2) ti=
me
> > spent serially checking in which index the address appears at. Of cours=
e,
> > this implies that all addresses up to a certain index have to be export=
ed
> > into the CSV as well, but most wallets I know of like Core, Electrum
> > already store addresses like that.
> >
> > Also if you do this, you will need to group all the transaction records
> > before the address records or vice versa - you can use lexigraphical
> > sorting if you want (ie. Addresses before Transactions). The benefit of
> > this separation of parts is that wallets can split the imported address
> > records from the transaction records internally, and feed them to separ=
ate
> > functions which set these labels internally.
> >
> > If you decide on doing it this way, then you need a 3rd column to ident=
ify
> > the item type, and also you should quote the label (see below). I stron=
gly
> > recommend using numbers for identification as opposed to character stri=
ngs,
> > so you don't have to worry about localization or character case issues.
> > There is always one unique number, but there could be multiple strings =
that
> > reference the same type. This will complicate importing functions.
> >
> > If you insist on include Input and Output types then they can both be
> > specified as <txid>:<index> if you do this change. They won't be used t=
o
> > determine the type anyway.
> >
> > > The fields may be quoted, but this is unnecessary, as the first comma=
 in
> > > the line will always be the delimiter.
> > Don't implement it like that, because that will break CSV parsers which
> > expect a fixed amount of rows in each record (2 in the header, and some
> > rows have >2 rows). It's better to mandate that they should always be
> > double-quoted, since only wallets will generate label exports anyway. I=
f
> > you plan to use headers then the 3rd column can be blank for it (or you=
 can
> > split the version and flags from each other).
> >
> > > =3D=3DImporting=3D=3D
> > >
> > > When importing, a naive algorithm may simply match against any refere=
nce,
> > > but it is possible to disambiguate between transactions, addresses,
> > inputs
> > > and outputs.
> > > For example in the following pseudocode:
> > > <pre>
> > >   if reference length < 64
> > >     Set address label
> > >   else if reference length =3D=3D 64
> > >     Set transaction label
> > >   else if reference contains '<'
> > >     Set input label
> > >   else
> > >     Set output label
> > > </pre>
> > The importing code is too naive and in its current form will prevent th=
e
> > BIP from getting a number. It is perhaps the single most important part=
 of
> > a BIP. When implementing an importer, it should utilize a dedicate item
> > type field that unambiguously identifies the item. So the naive importe=
r is
> > not good, you need use a 3rd column for that like I explained above, so
> > that the importer becomes robust.
> >
> > In summary (exclamation marks indicate severity - one means low, two me=
ans
> > medium, and three means high):
> >
> > 1. Convert the header into a version line with optional flags, otherwis=
e
> > nobody can extend this format without compatibility issues (!)
> > 2. Get rid of the specs related to file compression (!!!)
> > 3. Add a 3rd column for item type (address, transaction etc.) preferabl=
y
> > as numeric constants and grouping items of one type after items of anot=
her
> > type, or if you insist on strings, then only recognize their Titlecase
> > ASCII versions <spreadsheet software like Excel always tries to titleca=
se
> > the words> (!!)
> > 4. Require double quotes around the label (or single quotes if you pref=
er,
> > as long as spreadsheet software doesn't choke on them) (!!)
> > 5. Require sorting the records according to the order they are stored i=
n
> > the wallet implementation. (!)
> > 6. Consider getting rid of Input and Output item types. (!)
> > 7. And last and most importantly, please write a more robust importer
> > algorithm in the example given by the BIP, because code in BIPs are
> > frequently used as references for software. (!!!)
> >
> > I hope you will consider these points in future revisions of your BIP.
> >
> > - Ali
> >
> > [1] https://github.com/snyk/zip-slip-vulnerability
> >
> > On Wed, 24 Aug 2022 11:18:43 +0200, craigraw@gmail.com wrote:
> > > Hi all,
> > >
> > > I would like to propose a BIP that specifies a format for the export =
and
> > > import of labels from a wallet. While transferring access to funds ac=
ross
> > > wallet applications has been made simple through standards such as BI=
P39,
> > > wallet labels remain siloed and difficult to extract despite their va=
lue,
> > > particularly in a privacy context.
> > >
> > > The proposed format is a simple two column CSV file, with the referen=
ce
> > to
> > > a transaction, address, input or output in the first column, and the
> > label
> > > in the second column. CSV was chosen for its wide accessibility,
> > especially
> > > to users without specific technical expertise. Similarly, the CSV fil=
e
> > may
> > > be compressed using the ZIP format, and optionally encrypted using AE=
S.
> > >
> > > The full text of the BIP can be found at
> > > https://github.com/craigraw/bips/blob/master/bip-wallet-labels.mediaw=
iki
> > > and also copied below.
> > >
> > > Feedback is appreciated.
> > >
> > > Thanks,
> > > Craig Raw
> > >
> > > ---
> > >
> > > <pre>
> > >   BIP: wallet-labels
> > >   Layer: Applications
> > >   Title: Wallet Labels Export Format
> > >   Author: Craig Raw <craig@sparrowwallet.com>
> > >   Comments-Summary: No comments yet.
> > >   Comments-URI:
> > > https://github.com/bitcoin/bips/wiki/Comments:BIP-wallet-labels
> > >   Status: Draft
> > >   Type: Informational
> > >   Created: 2022-08-23
> > >   License: BSD-2-Clause
> > > </pre>
> > >
> > > =3D=3DAbstract=3D=3D
> > >
> > > This document specifies a format for the export of labels that may be
> > > attached to the transactions, addresses, input and outputs in a walle=
t.
> > >
> > > =3D=3DCopyright=3D=3D
> > >
> > > This BIP is licensed under the BSD 2-clause license.
> > >
> > > =3D=3DMotivation=3D=3D
> > >
> > > The export and import of funds across different Bitcoin wallet
> > applications
> > > is well defined through standards such as BIP39, BIP32, BIP44 etc.
> > > These standards are well supported and allow users to move easily bet=
ween
> > > different wallets.
> > > There is, however, no defined standard to transfer any labels the use=
r
> > may
> > > have applied to the transactions, addresses, inputs or outputs in the=
ir
> > > wallet.
> > > The UTXO model that Bitcoin uses makes these labels particularly valu=
able
> > > as they may indicate the source of funds, whether received externally=
 or
> > as
> > > a result of change from a prior transaction.
> > > In both cases, care must be taken when spending to avoid undesirable
> > leaks
> > > of private information.
> > > Labels provide valuable guidance in this regard, and have even become
> > > mandatory when spending in several Bitcoin wallets.
> > > Allowing users to export their labels in a standardized way ensures t=
hat
> > > they do not experience lock-in to a particular wallet application.
> > > In addition, by using common formats, this BIP seeks to make manual o=
r
> > bulk
> > > management of labels accessible to users without specific technical
> > > expertise.
> > >
> > > =3D=3DSpecification=3D=3D
> > >
> > > In order to make the import and export of labels as widely accessible=
 as
> > > possible, this BIP uses the comma separated values (CSV) format, whic=
h is
> > > widely supported by consumer, business, and scientific applications.
> > > Although the technical specification of CSV in RFC4180 is not always
> > > followed, the application of the format in this BIP is simple enough =
that
> > > compatibility should not present a problem.
> > > Moreover, the simplicity and forgiving nature of CSV (over for exampl=
e
> > > JSON) lends itself well to bulk label editing using spreadsheet and t=
ext
> > > editing tools.
> > >
> > > A CSV export of labels from a wallet must be a UTF-8 encoded text fil=
e,
> > > containing one record per line, with records containing two fields
> > > delimited by a comma.
> > > The fields may be quoted, but this is unnecessary, as the first comma=
 in
> > > the line will always be the delimiter.
> > > The first line in the file is a header, and should be ignored on impo=
rt.
> > > Thereafter, each line represents a record that refers to a label appl=
ied
> > in
> > > the wallet.
> > > The order in which these records appear is not defined.
> > >
> > > The first field in the record contains a reference to the transaction=
,
> > > address, input or output in the wallet.
> > > This is specified as one of the following:
> > > * Transaction ID (<tt>txid</tt>)
> > > * Address
> > > * Input (rendered as <tt>txid<index</tt>)
> > > * Output (rendered as <tt>txid>index</tt> or <tt>txid:index</tt>)
> > >
> > > The second field contains the label applied to the reference.
> > > Exporting applications may omit records with no labels or labels of z=
ero
> > > length.
> > > Files exported should use the <tt>.csv</tt> file extension.
> > >
> > > In order to reduce file size while retaining wide accessibility, the =
CSV
> > > file may be compressed using the ZIP file format, using the <tt>.zip<=
/tt>
> > > file extension.
> > > This <tt>.zip</tt> file may optionally be encrypted using either AES-=
128
> > or
> > > AES-256 encryption, which is supported by numerous applications inclu=
ding
> > > Winzip and 7-zip.
> > > In order to ensure that weak encryption does not proliferate, importe=
rs
> > > following this standard must refuse to import <tt>.zip</tt> files
> > encrypted
> > > with the weaker Zip 2.0 standard.
> > > The textual representation of the wallet's extended public key (as
> > defined
> > > by BIP32, with an <tt>xpub</tt> header) should be used as the passwor=
d.
> > >
> > > =3D=3DImporting=3D=3D
> > >
> > > When importing, a naive algorithm may simply match against any refere=
nce,
> > > but it is possible to disambiguate between transactions, addresses,
> > inputs
> > > and outputs.
> > > For example in the following pseudocode:
> > > <pre>
> > >   if reference length < 64
> > >     Set address label
> > >   else if reference length =3D=3D 64
> > >     Set transaction label
> > >   else if reference contains '<'
> > >     Set input label
> > >   else
> > >     Set output label
> > > </pre>
> > >
> > > Importing applications may truncate labels if necessary.
> > >
> > > =3D=3DTest Vectors=3D=3D
> > >
> > > The following fragment represents a wallet label export:
> > > <pre>
> > > Reference,Label
> > >
> > c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b?,Trans=
action
> > > 1A69TXnEM2ms9fMaY9UuiJ7415X7xZaUSg,Address
> > > c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b?<0,I=
nput
> > >
> > c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b?>0,Out=
put
> > >
> > c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b?:0,Out=
put
> > > (alternative)
> > > </pre>
> > >
> > > =3D=3DReference Implementation=3D=3D
> > >
> > > TBD