From: AdamISZ <AdamISZ@protonmail•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds
Date: Tue, 10 May 2022 19:03:16 +0000 [thread overview]
Message-ID: <6IPqvNW2vQcHQLhUgSmQQLqtnV0RGrsUfnoUMKgv0SDQpVvKh7PIqJOKNazzgEzGE2W5OHHrlEtmg9lapjbiSjTpUuxqPmsiFua2P_ZN_FY=@protonmail.com> (raw)
In-Reply-To: <Xjq4gzy3me86tG6sYumDq16JE8EpRSnC90Ao-02Fyz3i55vRlLY7QKbW9TdaSJg8hiclxpBqhW93CtNgeCzVmbN3CDaW35P3BZwYp1o54H0=@protonmail.com>
------- Original Message -------
On Tuesday, May 10th, 2022 at 17:54, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> Good morning waxwing,
<snip>
>
> Ah, yes, now I remember.
> I discussed this with Tamas as well in the past and that is why we concluded that in defiads, each UTXO can host at most one advertisement at any one time.
> In the case of defiads there would be a sequence counter where a higher-sequenced advertisement would replace lower-sequenced advertisement, so you could update, but at any one time, for a defiads node, only one advertisement per UTXO could be used.
> This assumed that there would be a defiads network with good gossip propagation so our thinking at the time was that a higher-sequenced advertisement would quickly replace lower-sequenced ones on the network.
> But it is simpler if such replacement would not be needed, and you could then commit to the advertisement directly on the UTXO via a tweak.
>
> Each advertisement would also have a specific application ID that it applied to, and applications on top of defiads would ask the local defiads node to give it the ads that match a specific application ID, so a UTXO could only be used for one application at a time.
> This would be equivalent to domain separation tags that waxwing mentions.
>
> Regards,
> ZmnSCPxj
>
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
next prev parent reply other threads:[~2022-05-10 19:03 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-01 8:57 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 [this message]
2022-05-10 19:28 ` AdamISZ
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='6IPqvNW2vQcHQLhUgSmQQLqtnV0RGrsUfnoUMKgv0SDQpVvKh7PIqJOKNazzgEzGE2W5OHHrlEtmg9lapjbiSjTpUuxqPmsiFua2P_ZN_FY=@protonmail.com' \
--to=adamisz@protonmail$(echo .)com \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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