Re: [bitcoin-dev] Packaged Transaction Relay
> Hi Eric,
>
>
> This email wasn't answered by anyone on mailing list however I did some
> research about packages yesterday including this email and below are my
> observations, questions etc.
Hello, thanks for the reply.
> > The sole objective, as expressed in the OP proposal, is to:
> >
> > "Propagate transactions that are incentive-compatible to mine, even if they
> don't meet minimum feerate alone."
>
> According to [bitcoinops][1]: Without package relay, it’s not possible to
> effectively CPFP fee bump a transaction that’s below the minimum feerate
> nodes accept.
Yes, the problem statement is not in question, just the mechanism of
resolution. The problem of stuck txs arises from minimum fee rate policy, which
is a necessary DOS guard.
A secondary issue is that of orphan relay. As a node must allow receipt of
orphans, it has no means to differentiate a flood of unconfirmable txs from
those that are confirmable.
> Matt Corallo's thoughts in a bitcoin core [issue][2]:
>
> "Matt Corallo recently wrote about an example on the bitcoin-dev mailing list
> involving lightning transactions, where pre-signed transactions might be
> broadcast to the blockchain long after they were generated, and thus not
> have been created with a fee that is sufficient to be confirmed quickly (or
> even be accepted to node mempools). In such situations, channel
> participants may need to use chained transactions (CPFP) in order to increase
> the confirmation speed of such transactions, and that implies we may need
> to introduce a mechanism for those parent transactions to be relayed along
> with their higher feerate children, even if the parent transaction would be
> rejected by itself."
While this is a valid scenario, the problems directly affect Bitcoin. Those
problems propagate to layers, but are not unique to layering.
> 1)Is it possible to have multiple pre-signed transactions with different fee
> rates in a range? Example: PSBT1: 5 sat/vbyte, PSBT2: 10 sat/vbyte, PSBT3: 20
> sat/vbyte and PSBT4: 100 sat/vbyte
If by "range" you mean a connected tx subgraph, I don't see why not. But note
that nodes only operate over signed txs. PSBT is a wallet workflow.
> 2)How would covenants affect this problem?
There are a good number of covenant proposals, though I assume they are all
implemented within script. If a tx is confirmable and satisfies fee rate (for
DOS protection), it is relayable. Covenants affect confirmability and should
not have any unique impact on relay.
> 3)How often does it happen that a pre-signed tx gets rejected by nodes
> because it did not meet the minimum fee rate? Is it predictable and could be
> managed in a different way?
Always. Only signed transactions are accepted. But assuming you are referring
to a transaction that has been produced by a pre-signing workflow, I'm not sure
how this would be distinct from any other tx.
> After reading several links related to packages and bitcoin core pull
> requests,
> I found it anti-bitcoin to introduce so much complexity because its not
> possible to CPFP fee bump a tx below minimum fee rate.
I'm not sure I follow this, maybe you could reword it. But it seems that you
are saying that CPFP fee-bumping is a problem scenario and the complexity of
the proposed solutions are not justified by such scenarios.
I would say that the problem is real, and that the least complex option is
generally preferred. There are always tradeoffs, and balancing these is part of
protocol development. But as a rule, complexity within a protocol
(communication) is to be avoided where possible.
> > Furthermore any tx that is "stuck" can be freed by simply sending another
> tx. The nodes at which the tx has become stuck will just package it up and
> relay it to peers. In other words, there is no impact on wallet implementation
> apart from raising the aggregate fee using a descendant transaction.
>
> It is easy to send another tx if there is only one user involved however
> packages are trying to fix issues in which multiple users and transaction pre-
> signed between them are involved. So, it will be difficult to coordinate and
> create new pre-signed transactions in some cases although it is possible for
> some use cases.
Given that nodes do not deal in presigned txs, this coordination difficulty
could not be increased in any scenario.
A node produces sets of txs ("packages") dynamically to satisfy its peer's
feerate. When a wallet broadcasts a tx/package to a node, it is operating as a
peer on the p2p network. The wallet simply implements the same dynamic
packaging algorithm as any peer - because it is a peer.
> > This is barely a protocol change - it's primarily implementation. All that
> should be required is an additional INV element type, such as
> MSG_TX_PACKAGE.
>
> > * All elements of MSG_TX_PACKAGE in one INV message MUST to be of
> the same package.
> > * A package MUST must define a set that can be mined into one block
>
Re: [bitcoin-dev] Packaged Transaction Relay
Hi Eric, This email wasn't answered by anyone on mailing list however I did some research about packages yesterday including this email and below are my observations, questions etc. > The sole objective, as expressed in the OP proposal, is to: > > "Propagate transactions that are incentive-compatible to mine, even if they > don't meet minimum feerate alone." According to [bitcoinops][1]: Without package relay, it’s not possible to effectively CPFP fee bump a transaction that’s below the minimum feerate nodes accept. Matt Corallo's thoughts in a bitcoin core [issue][2]: "Matt Corallo recently wrote about an example on the bitcoin-dev mailing list involving lightning transactions, where pre-signed transactions might be broadcast to the blockchain long after they were generated, and thus not have been created with a fee that is sufficient to be confirmed quickly (or even be accepted to node mempools). In such situations, channel participants may need to use chained transactions (CPFP) in order to increase the confirmation speed of such transactions, and that implies we may need to introduce a mechanism for those parent transactions to be relayed along with their higher feerate children, even if the parent transaction would be rejected by itself." 1)Is it possible to have multiple pre-signed transactions with different fee rates in a range? Example: PSBT1: 5 sat/vbyte, PSBT2: 10 sat/vbyte, PSBT3: 20 sat/vbyte and PSBT4: 100 sat/vbyte 2)How would covenants affect this problem? 3)How often does it happen that a pre-signed tx gets rejected by nodes because it did not meet the minimum fee rate? Is it predictable and could be managed in a different way? After reading several links related to packages and bitcoin core pull requests, I found it anti-bitcoin to introduce so much complexity because its not possible to CPFP fee bump a tx below minimum fee rate. > Furthermore any tx that is "stuck" can be freed by simply sending another tx. > The nodes at which the tx has become stuck will just package it up and relay > it to peers. In other words, there is no impact on wallet implementation > apart from raising the aggregate fee using a descendant transaction. It is easy to send another tx if there is only one user involved however packages are trying to fix issues in which multiple users and transaction pre-signed between them are involved. So, it will be difficult to coordinate and create new pre-signed transactions in some cases although it is possible for some use cases. > This is barely a protocol change - it's primarily implementation. All that > should be required is an additional INV element type, such as MSG_TX_PACKAGE. > * All elements of MSG_TX_PACKAGE in one INV message MUST to be of the same > package. > * A package MUST must define a set that can be mined into one block > (size/sigops constraint). > * A package SHOULD not contain confirmed txs (a race may cause this). > * A package MUST minimally satisfy peer.feerate. > * A partial tx order, as in the manner of the block.txs ordering, MUST be > imposed. > * A node SHOULD drop a peer that sends a package (or tx) below node.feerate. > * A node MAY drop a peer that sends a non-minimal package according to > node.feerate. This makes sense particularly if multiple node implementations are used in future. My other questions: a)If a package has tx1, tx2, tx3, tx4 and tx5 and miner just include tx1 and tx2 in the block, how does this affect the projects considered for packages proposal? b)How does changing the order of txs in a package affect these transactions? c)Do packages introduce more attack vectors in bitcoin for front running or MEV? MEV in bitcoin currently only affects the projects that are considered in packages proposal. d)What if the package contains a transactions with sanctioned address? e)Why would miners use packages if the existing scenario in terms of fees per block is beneficial for them? /dev/fd0 [1]: https://bitcoinops.org/en/topics/package-relay/ [2]: https://github.com/bitcoin/bitcoin/issues/14895 Sent with Proton Mail secure email. --- Original Message --- On Thursday, June 9th, 2022 at 4:13 AM, Eric Voskuil via bitcoin-dev wrote: > Hi Suhas/Gloria, > > Good questions. I've started a new thread because it became something else... > > Various ideas about packaging seem to be focused on the idea of an atomic > message that is gossiped around the network like a transaction or block. From > my perspective that seems to create a set of problems without good solutions, > and it is not a proper analogy to those atomic structures. It may be worth > taking the time to step back and take a close look at the underlying > objective. > > The sole objective, as expressed in the OP proposal, is to: > > "Propagate transactions that are incentive-compatible to mine, even if they > don't meet minimum feerate alone." > > Effectively producing this outcome with an
Re: [bitcoin-dev] New transaction policies (nVersion=3) for contracting protocols
Hi Greg, Antoine, Bastien, Thanks very much for the feedback! I interpret most of the discussion around limitations as ideas for future improvements rather than criticisms of the proposal (please correct me if I'm wrong). I'll try to respond to as much as possible. Also I realize that I didn't contextualize this proposal clearly enough; it is very tailored for LN Penalty and definitely doesn't close all pinning attacks possible (sorry for confusing anyone). I also agree that some bits can be a little ugly or tack-on; I would definitely prefer a comprehensive RBF revamp to fix all our problems and enable other fee-bumping strategies such as sign-ANYONECANPAY-then-bring-your-own-fees-by-adding-inputs-at-broadcast. I was hoping to get some ideas with the "RBF Improvements" post in January, but it doesn't seem like we're much closer to a workable proposal. I think this is a minimally-invasive step that works for Lightning today, a small fix similar to CPFP carve out. > As you likely know from previous discussions the biggest scenario this does not fix in my estimation is ANYONECANPAY situations. If the parent transaction can be "inflated" by tacking on additional inputs, this means the total weight of the parent tx lowers the effective feerate of the package. (For more context to other readers I wrote an explanation for this in "SIGHASH_ANYONECANPAY Pinning" section of RBF ML post). Yes, this unfortunately doesn't fix any of the existing pinning attacks for single transaction RBF but also doesn't make them worse. This boils down to adding an incentive compatibility rule that ensures you can't replace a transaction with something that will confirm slower. Package RBF has an ancestor feerate-based rule for this (note it is quite conservative and not perfect). So in the scenario above with the "inflated" parent that was signed ACP, the replacement would be rejected because the package ancestor feerate is lower than the feerate of what is being replaced. But it is imperfect (explained below) and thus I wouldn't recommend it for single transaction replacement. So that attack still exists for single transactions, yes. The strategy of using ACP to bring-your-own-fees has its own challenges but hopefully has no current use cases as you say. AFAIK LN Penalty is not affected by this since it doesn't use ACP, though obviously I agree we should fix it for the future. So when I said "this is intended for fee-bumping presigned txns in contracting protocols," I should have said "this is intended for fee-bumping presigned txns specifically using CPFP and anchor outputs." Apologies for forgetting to contextualize, I've been sitting on this for too long. > The other scenario it doesn't really fix is where HTLC/commitment-like transactions are being resolved in a batch, but due to relative time constraints, you may want to accelerate some and not others. Now you must pay higher rates to replace all of the transaction bumps. This is a "self-pin" and "get good at utxos noob" type problem, but it's something that axing rule#3 in favor of a Replace-by-ancestor-feerate system would get us. I understand you to mean "if you don't have enough UTXOs and you're forced to batch-bump, you over-pay because you need to bring them all to the highest target feerate." Isn't this kind of separate, wallet-related problem? Contracting or not, surely every wallet needs to have enough UTXOs to not batch transactions that shouldn't be batched... I don't see how a replace-by-ancestor-feerate policy would make any difference for this? Also in general I'd like to reiterate that ancestor feerate is not a panacea to all our RBF incentive compatibility concerns. Like individual feerate, unless we run the mining algorithm, it cannot tell us exactly how quickly this transaction would be mined. We're estimating the incentive compatibility of the original transaction(s) and replacement transaction(s), with the goal of not letting a transaction replace something that would have been more incentive compatible to mine. As such, we don't want to overestimate how good the replacement is, and we don't want to underestimate how good the original transactions are. This rule "The minimum between package feerate and ancestor feerate of the child is not lower than the individual feerates of all directly conflicting transactions and the ancestor feerates of all original transactions" is a conservative estimate. > Would kind of be nice if package RBF would detect a "sibling output spend" conflict, and knock it out of the mempool via the other replacement rules? Getting rid of the requirement to 1 block csv lock every output would be quite nice from a smart contracting composability point of view. Interesting, so when a transaction hits a mempool tx's descendant limit, we consider evicting one of its descendants in favor of this transaction, based on the RBF rules. Cool idea! After chewing on this for a bit, I think this *also* just boils down to the fact that
Re: [bitcoin-dev] New transaction policies (nVersion=3) for contracting protocols
Bastien, > This may be already covered by the current package RBF logic, in that scenario we are simply replacing [ParentTx, ChildTx1] with [ParentTx, ChildTx2] that pays more fees, right? For clarification, package RBF is ParentTx*s*(plural), and ChildTx(singular), so it might be a bit more complicated than we're thinking, and currently the V3 proposal would first de-duplicate the ParentTx based on what is in the mempool, then look at the "rest" of the transactions as a package, then individually. Not the same, not sure how different. I'll defer to experts. Best, Greg On Mon, Sep 26, 2022 at 11:48 AM Bastien TEINTURIER via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Thanks Gloria for this great post. > > This is very valuable work for L2 contracts, and will greatly improve > their security model. > > > "Only 1 anchor output? What if I need to bump counterparty's commitment > tx in mempool?" > > You won't need to fee-bump a counterparty's commitment tx using CPFP. > > You would just package RBF it by attaching a high-feerate child to > > your commitment tx. > > Note that we can also very easily make that single anchor spendable by > both participants (or even anyone), so if you see your counterparty's > commitment in your mempool, you can bump it without publishing your > own commitment, which is quite desirable (your own commitment tx has > CSV delays on your outputs, whereas your counterparty's commitment tx > doesn't). > > > "Is this a privacy issue, i.e. doesn't it allow fingerprinting LN > transactions based on nVersion?" > > I agree with you, this isn't worse than today, unilateral closes will > probably always be identifiable on-chain. > > > Would kind of be nice if package RBF would detect a "sibling output > spend" > > conflict, and knock it out of the mempool via the other replacement > rules? > > Getting rid of the requirement to 1 block csv lock every output would be > > quite nice from a smart contracting composability point of view. > > +1, that would be very neat! > > This may be already covered by the current package RBF logic, in that > scenario we are simply replacing [ParentTx, ChildTx1] with > [ParentTx, ChildTx2] that pays more fees, right? > > > 1) I do think that we should seriously consider allowing OP_TRUE to > become > > a standard script type as part of this policy update. If pinning is > solved, > > then there's no reason to require all those extra bytes for "binding" an > > anchor to a specific wallet/user. We can save quite a few bytes by having > > the input be empty of witness data. > > 2) If we allow for a single dust-value(0 on up) output which is > immediately > > spent by the package, anchors become even easier to to design. No value > has > > to be "sapped" from contract participants to make an anchor output. > There's > > more complications for this, such as making sure the parent transaction > is > > dropped if the child spend is dropped, but maybe it's worth the squeeze. > > I also think both of these could be quite useful. This would probably > always > be used in combination with a parent transaction that pays 0 fees, so the > 0-value output would always be spent in the same block. > > But this means we could end up with 0-value outputs in the utxo set, if for > some reason the parent tx is CPFP-ed via another output than the 0-value > one, > which would be a utxo set bloat issue. But I'd argue that we're probably > already creating utxo set bloat with the 330 sat anchor outputs (especially > since we use two of them, but only one is usually spent), so it would > probably be *better* than what we're doing today. > > Thanks, > Bastien > > Le lun. 26 sept. 2022 à 03:22, Antoine Riard via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> a écrit : > >> Hi Gloria, >> >> Thanks for the progress on package RBF, few early questions. >> >> > 2. Any descendant of an unconfirmed V3 transaction must also be V3. >> >> > 3. An unconfirmed V3 transaction cannot have more than 1 descendant. >> >> If you're a miner and you receive a non-V3, second descendant of an >> unconfirmed V3 transaction, if the offered fee is in the top mempool >> backlog, I think you would have an interest to accept such a transaction. >> >> So I'm not sure if those two rules are compatible with miners >> incentives... >> >> > 4. A V3 transaction that has an unconfirmed V3 ancestor cannot be >> >larger than 1000 virtual bytes. >> >> If I understand correctly the 1000 vb upper bound rational, it would be >> to constraint the pinning counterparty to attach a high fee to a child due >> to the limited size, if they would like this transaction to be stuck in the >> network mempools. By doing so this child has high odds to confirm. >> >> I still wonder if this compatible with miner incentives in period of >> empty mempools, in the sense that if you've already a V3 transaction of >> size 100Kvb offering 2 sat/vb, it's more interesting than a V3 replacement >> candidate of size
Re: [bitcoin-dev] New transaction policies (nVersion=3) for contracting protocols
Thanks Gloria for this great post. This is very valuable work for L2 contracts, and will greatly improve their security model. > "Only 1 anchor output? What if I need to bump counterparty's commitment tx in mempool?" > You won't need to fee-bump a counterparty's commitment tx using CPFP. > You would just package RBF it by attaching a high-feerate child to > your commitment tx. Note that we can also very easily make that single anchor spendable by both participants (or even anyone), so if you see your counterparty's commitment in your mempool, you can bump it without publishing your own commitment, which is quite desirable (your own commitment tx has CSV delays on your outputs, whereas your counterparty's commitment tx doesn't). > "Is this a privacy issue, i.e. doesn't it allow fingerprinting LN transactions based on nVersion?" I agree with you, this isn't worse than today, unilateral closes will probably always be identifiable on-chain. > Would kind of be nice if package RBF would detect a "sibling output spend" > conflict, and knock it out of the mempool via the other replacement rules? > Getting rid of the requirement to 1 block csv lock every output would be > quite nice from a smart contracting composability point of view. +1, that would be very neat! This may be already covered by the current package RBF logic, in that scenario we are simply replacing [ParentTx, ChildTx1] with [ParentTx, ChildTx2] that pays more fees, right? > 1) I do think that we should seriously consider allowing OP_TRUE to become > a standard script type as part of this policy update. If pinning is solved, > then there's no reason to require all those extra bytes for "binding" an > anchor to a specific wallet/user. We can save quite a few bytes by having > the input be empty of witness data. > 2) If we allow for a single dust-value(0 on up) output which is immediately > spent by the package, anchors become even easier to to design. No value has > to be "sapped" from contract participants to make an anchor output. There's > more complications for this, such as making sure the parent transaction is > dropped if the child spend is dropped, but maybe it's worth the squeeze. I also think both of these could be quite useful. This would probably always be used in combination with a parent transaction that pays 0 fees, so the 0-value output would always be spent in the same block. But this means we could end up with 0-value outputs in the utxo set, if for some reason the parent tx is CPFP-ed via another output than the 0-value one, which would be a utxo set bloat issue. But I'd argue that we're probably already creating utxo set bloat with the 330 sat anchor outputs (especially since we use two of them, but only one is usually spent), so it would probably be *better* than what we're doing today. Thanks, Bastien Le lun. 26 sept. 2022 à 03:22, Antoine Riard via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a écrit : > Hi Gloria, > > Thanks for the progress on package RBF, few early questions. > > > 2. Any descendant of an unconfirmed V3 transaction must also be V3. > > > 3. An unconfirmed V3 transaction cannot have more than 1 descendant. > > If you're a miner and you receive a non-V3, second descendant of an > unconfirmed V3 transaction, if the offered fee is in the top mempool > backlog, I think you would have an interest to accept such a transaction. > > So I'm not sure if those two rules are compatible with miners incentives... > > > 4. A V3 transaction that has an unconfirmed V3 ancestor cannot be > >larger than 1000 virtual bytes. > > If I understand correctly the 1000 vb upper bound rational, it would be to > constraint the pinning counterparty to attach a high fee to a child due to > the limited size, if they would like this transaction to be stuck in the > network mempools. By doing so this child has high odds to confirm. > > I still wonder if this compatible with miner incentives in period of empty > mempools, in the sense that if you've already a V3 transaction of size > 100Kvb offering 2 sat/vb, it's more interesting than a V3 replacement > candidate of size 1000 vb offering 10 sat/vb. It could be argued the former > should be conserved. > > (That said, the hard thing with any replacement strategy we might evict a > parent transaction *now* to which is attached a high-feerate child *latter* > making for a utxo considered the best ancestor set. Maybe in the long-term > miners should keep every transaction ever accepted...) > > > (Lower bound) the smaller this limit, the fewer UTXOs a child may use > > to fund this fee-bump. For example, only allowing the V3 child to have > > 2 inputs would require L2 protocols to manage a wallet with high-value > > UTXOs and make batched fee-bumping impossible. However, as the > > fee-bumping child only needs to fund fees (as opposed to payments), > > just a few UTXOs should suffice. > > Reminder for L2 devs, batched fee-bumping of time-sensitive confirmations > of
Re: [bitcoin-dev] BIP Proposal: Wallet Labels Export Format
Following discussion with several wallet developers, I have come to the
conclusion that the secondary goal of managing labels in non-specialized
applications must be sacrificed in order to achieve the primary goal of
wide implementation across different wallets. While this tradeoff was
perhaps inevitable, it was worth a try!
As such I have rewritten the specification to use JSON, specifically the
JSON Lines format suggested by Ryan Havar and others (thank you). This
allows documents to be split or streamed, and is convenient for
command-line processing. The format is also now self describing via a type
field, permitting simple type identification (thank you Ali Sherief and
others). Public keys and xpubs have been added as types following further
suggestions. To keep the specification simple, compression and encryption
have been removed - with the strong recommendation to consider protecting
the data in a way suitable to its application.
The rewritten BIP can be found at
https://github.com/craigraw/bips/blob/master/bip-wallet-labels.mediawiki
It is perhaps simplest to understand it by looking at an example export:
{ "type": "tx", "ref":
"f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd",
"label": "Transaction" }
{ "type": "addr", "ref": "bc1q34aq5drpuwy3wgl9lhup9892qp6svr8ldzyy7c",
"label": "Address" }
{ "type": "pubkey", "ref":
"0283409659355b6d1cc3c32decd5d561abaac86c37a353b52895a5e6c196d6f448",
"label": "Public Key" }
{ "type": "input", "ref":
"f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd:0",
"label": "Input" }
{ "type": "output", "ref":
"f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd:1",
"label": "Output" }
{ "type": "xpub", "ref":
"xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8Nq...", "label": "Extended
Public Key" }
Feedback is always appreciated.
Craig
On Wed, Aug 24, 2022 at 11:18 AM Craig Raw 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 across
> wallet applications has been made simple through standards such as BIP39,
> wallet labels remain siloed and difficult to extract despite their value,
> particularly in a privacy context.
>
> The proposed format is a simple two column CSV file, with the reference 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 file may
> be compressed using the ZIP format, and optionally encrypted using AES.
>
> The full text of the BIP can be found at
> https://github.com/craigraw/bips/blob/master/bip-wallet-labels.mediawiki
> and also copied below.
>
> Feedback is appreciated.
>
> Thanks,
> Craig Raw
>
> ---
>
>
> BIP: wallet-labels
> Layer: Applications
> Title: Wallet Labels Export Format
> Author: Craig Raw
> 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
>
>
> ==Abstract==
>
> This document specifies a format for the export of labels that may be
> attached to the transactions, addresses, input and outputs in a wallet.
>
> ==Copyright==
>
> This BIP is licensed under the BSD 2-clause license.
>
> ==Motivation==
>
> 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 between
> different wallets.
> There is, however, no defined standard to transfer any labels the user may
> have applied to the transactions, addresses, inputs or outputs in their
> wallet.
> The UTXO model that Bitcoin uses makes these labels particularly valuable
> 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 that
> they do not experience lock-in to a particular wallet application.
> In addition, by using common formats, this BIP seeks to make manual or
> bulk management of labels accessible to users without specific technical
> expertise.
>
> ==Specification==
>
> In order to make the import and export of labels as widely accessible as
> possible, this BIP uses the comma separated values (CSV) format, which 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
