public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: AdamISZ <AdamISZ@protonmail.com>
To: Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>,
	ZmnSCPxj <ZmnSCPxj@protonmail.com>
Subject: Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds
Date: Tue, 10 May 2022 19:28:05 +0000	[thread overview]
Message-ID: <PFBgbTn4_7JXQaRMlMjZDVrGBIr4OKfMK1ftW38cY-8Qu6tm_GllxDOWEj7K4zHkmQz9jA9NO_9rT_UzTSw9rr3RneEKTNhz826LmEIWF7w=@protonmail.com> (raw)
In-Reply-To: <6IPqvNW2vQcHQLhUgSmQQLqtnV0RGrsUfnoUMKgv0SDQpVvKh7PIqJOKNazzgEzGE2W5OHHrlEtmg9lapjbiSjTpUuxqPmsiFua2P_ZN_FY=@protonmail.com>

> I suppose ultimately this brings up the question of the scope of this BIP. The abstract points out that the BIP contains both a definition of address derivation, but also how to sign fidelity bond certificates.
>
> My feeling is that the latter might be better not included? I note that the 'Motivation' section gives motivation for standardisation of derivation (this includes things like time schedule), but not the second area - certificate signing. I think the second area is much more tricky, but much more to the point is, isn't it the case that that second area, can be interpreted without consensus between wallet developers? So say you were a hardware wallet provider, or a "node in a box" provider - your customers want you to provide the ability move funds around, including e.g. moving funds out of an old Joinmarket wallet (in which say there is a now expired timelock address utxo) by just entering its BIP39 seed. If this BIP addresses that, it should be enough.
>
> I don't doubt that there's gains to be had from a broader community discussing and agreeing the details of how to create a fidelity bond certificate, but it's a separate, and more difficult, task.
>
> Cheers,
> waxwing/AdamISZ

Further to that last point, as the BIP draft currently says:

" Almost all wallets implementing this standard can use their
already-existing "Sign Message" function to sign the certificate
message. As the certificate message itself is always an ascii string,
the wallet may not need to specially implement this section at all but
just rely on users copypasting their certificate message into the
already-existing "Sign Message" user interface. This works as long as
the wallet knows how to use the private key of the timelocked address
for signing messages."

So, isn't that an argument that we don't need to specify the certificate message format here?

On the other hand, I can hardly disagree that it's worth presenting a kind of 'default' way of doing it. But I fear it is not at all simple to decide what a secure, general format should be (as per the discussion we started having here about domain separation tags).

Cheers,
waxwing/AdamISZ


  reply	other threads:[~2022-05-10 19:28 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-01  8:57 [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds Chris Belcher
2022-05-01  9:43 ` ZmnSCPxj
2022-05-01 10:01   ` Chris Belcher
2022-05-01 11:41     ` ZmnSCPxj
2022-05-02  9:23       ` Chris Belcher
2022-05-03  5:26         ` ZmnSCPxj
2022-05-03 18:03           ` Chris Belcher
2022-05-03 18:26             ` Eric Voskuil
2022-05-04  2:37               ` ZmnSCPxj
2022-05-04  4:04                 ` eric
2022-05-04  4:19                   ` ZmnSCPxj
     [not found]                 ` <01c401d86a5c$956ddbd0$c0499370$@voskuil.org>
2022-05-18  3:06                   ` eric
2022-05-18  6:29                     ` ZmnSCPxj
2022-05-21 21:36                       ` AdamISZ
2022-05-10 12:31     ` AdamISZ
2022-05-10 16:54       ` ZmnSCPxj
2022-05-10 19:03         ` AdamISZ
2022-05-10 19:28           ` AdamISZ [this message]
2022-05-13 10:02             ` Chris Belcher
2022-05-13 12:44               ` ZmnSCPxj
2022-05-15  9:13                 ` Chris Belcher
2022-05-16  0:00                   ` ZmnSCPxj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='PFBgbTn4_7JXQaRMlMjZDVrGBIr4OKfMK1ftW38cY-8Qu6tm_GllxDOWEj7K4zHkmQz9jA9NO_9rT_UzTSw9rr3RneEKTNhz826LmEIWF7w=@protonmail.com' \
    --to=adamisz@protonmail.com \
    --cc=ZmnSCPxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox