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 inev
Hello Craig,
Thank you for putting this proposal together. It is indeed another big
missing piece of the puzzle.
I would like to echo some of the comments already made by others (and you
yourself) on this thread, that this proposal seems to have some inherent
conflicts between the 2 goals it tries
Hello,
Thanks for this proposal.
I was trying to avoid adding more opinions / bike-shdding to the discussion and
didn’t want to particularly pick at any of the threads.
But, I think I’d like to at least voice at how important having a human
readable format for this is. CSV is indeed a format w
On Mon, Aug 29, 2022 at 9:12 AM Ali Sherief via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I am aware that business processes are mostly CSV file oriented
I disagree that business processes are mostly CSV. Amateur processes
maybe, but professional accounting, no. Trying to do
> I am attempting to achieve two goals with this proposal, primarily for the
> benefit of wallet users:
>
> Goal #1. Transfer labels between different wallet implementations
> Goal #2. Manage labels in applications outside of Bitcoin wallets (such as
> Excel)
>
> Much of the feedback so far has ind
Thanks for your feedback @Ali.
I am attempting to achieve two goals with this proposal, primarily for the
benefit of wallet users:
Goal #1. Transfer labels between different wallet implementations
Goal #2. Manage labels in applications outside of Bitcoin wallets (such as
Excel)
Much of the feedb
I think it might be a good idea to record something that can directly
connect the list of labels with the correct wallet. Imagine someone backs
up a bunch of label files and then forgets which wallet they apply to. Sure
you could probably look through the list of transactions, addresses, etc
and co
> This seems to run contrary with your point about letting users be in
> control of how they store this. Given that you can always connect together
> an output and its address or find the outputs at any address, it doesn't
> seem like it would actually leak any more information than just including
@Ali Thats some good well thought through and well articulated feedback. I
have one point of contention
> 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 way
I think these problems can be mitigated if the CSV format is strictly defined,
such as how I specified it in my previous message.
In particular, the parser has to recognize only one specific header line that
has a version number somewhere, or abort - and I still insist on quoting the
labels wit
Having previously developed an export format[1] for general cryptocurrency
transaction information, I can attest to the value of the human-readable CSV. I
was careful to mention the RFC 4180 spec so that implementations could avoid
the pitfalls of incorrect CSV encoding.
[1]: https://github.com
> Not only is JSON limited to editing only through specific software or text
> editors, but (in the latter case) it is fragile enough that a single missing
> character can cause an entire file to fail parsing. CSV is more forgiving in
> this regard.
I think quite simply: A forgiving format is n
Thanks for your thoughts Ryan.
Without reference to the quality feedback on this proposal, I was aware
when submitting it for review that it provides an excellent opportunity for
bike shedding. As developers, we have all experienced frustration with data
formats. One thing that I did not perhaps m
Thanks Clark - despite having worked in the Bitcoin wallet space for a
number of years I have not come across SLIP-0015. I did try to find prior
work on this - this one escaped me.
That said, having reviewed SLIP-0015, I think it has different design
goals. For example, it requires private key der
There is already a JSON standard that has been already used in the wild for
the last 7 years described in SLIP-0015 (mentioned by Clark in this
thread). No need to reinventing the wheel again.
On Wed 24. 8. 2022 at 21:44, Ryan Havar via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
Hi Craig,
This a really good proposal. I studied your BIP and I have some feedback on
some parts of it.
> The first line in the file is a header, and should be ignored on import.
>From past experience and lessons, most notably BIP39, it is important that a
>version byte is defined somewhere in
I'd strongly suggest not using CSV. Especially for a standard. I've worked with
it as an interchange format many a times, and it's always been a clusterfuck.
Right off the bat, you have stuff like "The fields may be quoted, but this is
unnecessary as the first comma in the line will always be th
On 2022-08-24 (Wed) at 11:18:43 +0200, Craig Raw via bitcoin-dev wrote:
> 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,
Craig,
Thanks for the proposal.
How does this proposal compare with SLIP-0015, which provides encryption by
default? Would it be worth exploring a merge of the two approaches?
https://github.com/satoshilabs/slips/blob/master/slip-0015.md
Clark
--- Original Message ---
On Wednesday, Au
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 va
20 matches
Mail list logo
