path: root/69/ce0130f36fc4b49cc7a3bd164b2ad26441e912

Delivery-date: Sun, 05 May 2024 07:54:36 -0700
Received: from mail-oi1-f184.google.com ([209.85.167.184])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDD7VM4YZ4NBBI5332YQMGQEYNEGGZI@googlegroups.com>)
	id 1s3dG6-0001K0-RO
	for bitcoindev@gnusha.org; Sun, 05 May 2024 07:54:36 -0700
Received: by mail-oi1-f184.google.com with SMTP id 5614622812f47-3c70bd60240sf819022b6e.0
        for <bitcoindev@gnusha.org>; Sun, 05 May 2024 07:54:34 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1714920869; cv=pass;
        d=google.com; s=arc-20160816;
        b=ZBIRib+bchbjrBvu0wcGMrUJ7gMVr/G7GUpcaua/cQVPTBNqBnrnLfQ75ciVB3J7dB
         rgvWa+WgdPMRUBL6AlMlAVcOt3yshC/7XFhOILYCPGERCC5M6HM9teCFEuoN9qV3Uu+P
         8oFOA4ZyXv0RP1kUvAxh1yKB5e2LoyUFhix4x79nMO15+H81ghGiida9j8gi+hfP6JP/
         X8IS7UZLzUIFZiB/FxaQwNhL9EQfdGm4f89sOsjLwH8ViCwcqX2nPAT6rm8RgFeMe1Lz
         vAnsjt6Bfmf9xNa/Ke6jx1IeU/4+LKSE2OVBmZo8pog4UTH6FD8rCwoNTBnmTySzp68n
         qSMQ==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:in-reply-to:from:content-language
         :references:to:subject:user-agent:mime-version:date:message-id
         :sender:dkim-signature;
        bh=TbTX9F2LOlbl9Fb+s3//xv/ZFbBIp6QHGzjtLsV7XLA=;
        fh=OLY8J4FT1jObS25a5mGonP2++MRJsFQjaWyVI6aDMwg=;
        b=zIFVWTLCKERISFmrM5Hgnj5pYHf/6eij8TDuWfL+Yvyw38m4dR/tQjZEfINsMRzELl
         vs8oEMDn6W/cJP59Q8LQLkhriCRcOw1w13fG7MiEFLwS7qQIfCZJxQ32riOrXsXl4XJR
         oMm2vplhLyF0XdCy3/GCI1TZovQ2oTdoU6Psrbeb3rdE2Ylr5mUfdwzkVl71JjitOB7K
         Y7rBRWXn2H/7xKhp/VQNksvhxTbCzOOouZBu8hztN4lBvynkDECkIYKd9zF6+moxBXMo
         gKg+4w3wYV9CZMQsCXA1lGequGWBSV/cIB+4Z9h0HLL9aDaTfxSO+KKQDkenxNSBP7hd
         RgIQ==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass (test mode) header.i=@dashjr.org header.s=zinan header.b=unX63pWl;
       spf=pass (google.com: domain of luke@dashjr.org designates 192.3.11.21 as permitted sender) smtp.mailfrom=luke@dashjr.org;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=dashjr.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1714920869; x=1715525669; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:in-reply-to:from:content-language:references:to
         :subject:user-agent:mime-version:date:message-id:sender:from:to:cc
         :subject:date:message-id:reply-to;
        bh=TbTX9F2LOlbl9Fb+s3//xv/ZFbBIp6QHGzjtLsV7XLA=;
        b=JolGcgXH/cnOxdNEFf1BPl4Z1aPqk9a/HSxeNR8VFxLWWtcoMr9OcSYBeXL79FFcER
         IJC35JRgy40Ft+XERdPHnsjQ//4J8wNjF3zzAEOAXmcClVmC8IdzqREP/CtA5fyyujeo
         Ev/kz4tFla1nFk4bHIsYBURdYbUWpSqoh0GzIp52hwsT7zyKBSBByKakCT6ELUZjdl5D
         ACrxPfXKQEC3Sv2YS/mLAvOTmb8IaiQDL6wO8qFLXc4cSI/fiaHLGDkl6o+v4k9iK71u
         wl+nXsGGXStEVqjJE8gez8DW3ofp0Rat0xKNYmMJuRQYUPsNCMil/JOYLwE7ZtYErIFx
         x5JQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1714920869; x=1715525669;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:in-reply-to:from:content-language:references:to
         :subject:user-agent:mime-version:date:message-id:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=TbTX9F2LOlbl9Fb+s3//xv/ZFbBIp6QHGzjtLsV7XLA=;
        b=PZUTrBqGm1eykiVSeDFIPwDsvT6yiP1fEs6Gqvg+Ha/Nvd/CdDQ9t4BLqJNIheWnGw
         XgPUDyJo/MXbqGOgzdKThJSOcji5Y9BCCUm8vHrOFLKZfnd49DW72k+DyOmLzQvVE1f7
         tfcmP2HMUw7qHy/C6WvWIk9n+xqAwtt8k5PgIeyMyHqhSA/1/VTIKamTe5Pn0Zii64WQ
         Vh/s/a9xxOisS//FZV++nO9Jn94DCdbjE5lxvBWDt/aD8bL7wZDD49VUqiwUJCVbz607
         IOco4yErcW59eMh5tOd58r6UDA7jzXUey8fZMcNod17qMNtMOMkdfEsE9DETlsUmgIIv
         1Bdw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCUHVuVnOLLrzeHtB6QIhSWudBEsip/F8BmGMa5fjJOGmFuZkdPI9NEMhj/dgzPrrPGui/MiRSMgnoYHy3iOMGiicqWH3m8=
X-Gm-Message-State: AOJu0YxboI4Wtl9zJBKtxmpAers9NRzA81RtNFYvnFLbI+hAiCuataHb
	YS68diaBh08k+/O31kmrwy5ezp8eNiz9GxPCq8o699p+VZ5pgsIN
X-Google-Smtp-Source: AGHT+IFmmE3a0BHZxjJxFnKjYMWgEtuSy7lTYCrnC++0Xng320jj0pzV08ROImO5HXcQl7COvdCDqQ==
X-Received: by 2002:a54:4706:0:b0:3c9:6b61:939 with SMTP id k6-20020a544706000000b003c96b610939mr1008107oik.36.1714920868774;
        Sun, 05 May 2024 07:54:28 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6214:250c:b0:69b:a44:bb68 with SMTP id
 6a1803df08f44-6a0fedc2761ls44146946d6.0.-pod-prod-00-us; Sun, 05 May 2024
 07:54:27 -0700 (PDT)
X-Received: by 2002:a05:6214:19ca:b0:6a0:a98a:4878 with SMTP id j10-20020a05621419ca00b006a0a98a4878mr852064qvc.2.1714920867323;
        Sun, 05 May 2024 07:54:27 -0700 (PDT)
Received: by 2002:a05:620a:4486:b0:790:ee24:5a3f with SMTP id af79cd13be357-7927105879dms85a;
        Sun, 5 May 2024 07:50:36 -0700 (PDT)
X-Received: by 2002:ac2:5dcd:0:b0:51a:c21b:73fb with SMTP id x13-20020ac25dcd000000b0051ac21b73fbmr4859847lfq.44.1714920634513;
        Sun, 05 May 2024 07:50:34 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1714920634; cv=none;
        d=google.com; s=arc-20160816;
        b=uT6L2OZBYnfdpPZwDhOUZYGm2lfanGKT4qebIQ1e7pXBYABTntpq7Yf+E+8VDt60wv
         yCjzVq+PsW+Il6Xbck3g1ox/Ip78epQTwroAYaymepoGUfQ6EzBSheq8kM0eCGiyXV6F
         iR5eklRVJdL0KyGzBTCVE7wiB/QyrmlGdt5t6hYsbZNx4qGGm4aYxpy1eqzWBuq0z55w
         M3+25R9Jo19z0D4oUbbRPzaWA+12ksisTbo7oo5UCKi7IJU7mxztVkukpJcMikezaAPf
         U7YUZ7Lnh5L/J6dY1zSHVVa3VCqVPXDe1NkmEEee/q8eVt2Oelq1Kzbp5LrdoebwQcAB
         nzHg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=in-reply-to:disposition-notification-to:from:content-language
         :references:to:subject:user-agent:mime-version:date:message-id
         :dkim-signature;
        bh=8dzj2/lCqV54yUeIUz+IRNDVOoo2hwoh1dEG7tqRsIE=;
        fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=;
        b=D50LmcF+QDiMJvnkOGraKpb2HItwTHmT7GDqTepAEJonLGV33PzphEL3nhXEgVPqwg
         malF2OFavFmcZ2Dw3JnGl5Cmj5IyCa3Eu0qEc5nMt4Ykqj4CycGUaAXTZ/32TUr9CzN5
         JxqPZ2KEL204XEVIibwZZDv1NiGbfGzv9Rh6+It4Gpvkd9xvjQ+/J/OK1fAYVcRn4s3c
         9qDIs59ATUcM7JOlunF6JDHNepImmlnKS9TVfXlqA0jB3IbcSMPgYUsSFMMOcL92xG+8
         Mjir9WGiKq/zXZSbfficNEjCj9s98sAMv3oVB1uoR4+bSPkf7Ou8oiv4eG9xow6Z//og
         BGww==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass (test mode) header.i=@dashjr.org header.s=zinan header.b=unX63pWl;
       spf=pass (google.com: domain of luke@dashjr.org designates 192.3.11.21 as permitted sender) smtp.mailfrom=luke@dashjr.org;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=dashjr.org
Received: from zinan.dashjr.org (zinan.dashjr.org. [192.3.11.21])
        by gmr-mx.google.com with ESMTP id br32-20020a056512402000b005193c802badsi189648lfb.8.2024.05.05.07.50.33
        for <bitcoindev@googlegroups.com>;
        Sun, 05 May 2024 07:50:34 -0700 (PDT)
Received-SPF: pass (google.com: domain of luke@dashjr.org designates 192.3.11.21 as permitted sender) client-ip=192.3.11.21;
Received: from [192.168.86.103] (99-39-46-195.lightspeed.dybhfl.sbcglobal.net [99.39.46.195])
	(Authenticated sender: luke-jr)
	by zinan.dashjr.org (Postfix) with ESMTPSA id A2C899805FF
	for <bitcoindev@googlegroups.com>; Sun,  5 May 2024 14:50:15 +0000 (UTC)
X-Hashcash: 1:23:240505:bitcoindev@googlegroups.com::3tt2rQ4+Ox12nJ4o:alVIT
Content-Type: multipart/alternative;
 boundary="------------Aujo0o2M0Gz3kQf5GKwVZcPV"
Message-ID: <b7861fc2-d980-4c3a-a472-ea7aead01692@dashjr.org>
Date: Sun, 5 May 2024 10:50:12 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [bitcoindev] BIP 322 use case
To: bitcoindev@googlegroups.com
References: <9004c5d4-6b9d-4ac1-834c-902ba4901e05n@googlegroups.com>
 <e617f6eb-dd11-4ca2-aba6-f80ace8863a8@dashjr.org>
 <5fcc4168-b4fd-4efd-b11c-6bbf852871ccn@googlegroups.com>
Content-Language: en-US, en-GB
From: Luke Dashjr <luke@dashjr.org>
In-Reply-To: <5fcc4168-b4fd-4efd-b11c-6bbf852871ccn@googlegroups.com>
X-Original-Sender: luke@dashjr.org
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass (test
 mode) header.i=@dashjr.org header.s=zinan header.b=unX63pWl;       spf=pass
 (google.com: domain of luke@dashjr.org designates 192.3.11.21 as permitted
 sender) smtp.mailfrom=luke@dashjr.org;       dmarc=pass (p=NONE sp=NONE
 dis=NONE) header.from=dashjr.org
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.7 (/)

This is a multi-part message in MIME format.
--------------Aujo0o2M0Gz3kQf5GKwVZcPV
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

Addresses are not tied to UTXOs. A proof-of-funds would only ever be=20
proving a numeric amount, not an address. While the proof would=20
necessarily use UTXOs behind-the-scenes, the signature would not be=20
committing to those specific UTXOs being the property of the=20
message-signer; this property is necessary for plausible deniability as=20
well as hot/cold wallet separation (multiple users could have signed=20
messages using the same UTXOs, yet reflecting distinct bitcoin claims).

Proof-of-sender, on the other hand, would make a claim to have sent a=20
specific txid and output index. Where this gets fairly complicated is=20
that it's somewhat important to have a mechanism that is compatible with=20
coinjoins, and without requiring the coinjoin participants to keep in=20
contact after the transaction is formed. It should able be compatible=20
with signing for transactions sent without preparation to sign messages=20
later. Ultimately, this requires delegation.

And since it wouldn't be great to be able to distinguish between=20
delegated and non-delegated, probably everything should just always be=20
delegated (perhaps to a deterministic keypair in some scenarios).

There's also potentially a use case for accepting an opcode rejects on=20
mainnet as invalid, so tapscripts can commit to sign-only script paths.

One thing all the current message signing standards lack is some kind of=20
magic heading to identify what they are, like bech32's "bc1" prefix.=20
This would be a trivial addition rather than trying to decode signatures=20
N different ways and seeing which verify.

I do agree being able to, at least internally, convert to/from PSBTs=20
would improve compatibility significantly. This was the approach I aimed=20
for when I tried to tackle it a few months ago. One limitation with=20
PSBTs is that each input needs non-witness and/or witness input data -=20
repeatedly, if multiple of the same transaction's outputs are used as=20
inputs. To address that, I was planning to support having them refer=20
back to previous inputs' data.

Hope all this helps, if someone wants to pick up the task...

Luke

On 5/5/24 08:09, Ali Sherief wrote:
> >=C2=A0But the feature with much higher demand is proof-of-funds and=20
> proof-of-sender, which BIP322 began to address, but turns out to be=20
> much more complicated than it seems at face value (I recently looked=20
> into this again as part of relaunching OCEAN).
>
> BIP322 is trying to figure two things: Collecting an authentic UTXO=20
> set for a given list of addresses, and actually making the signed=20
> message. It appears that only the latter of the two has been solved.
>
> I think one of the things that would help unstuck this is an RPC for=20
> getting the UTXO set of a list of addresses. I am aware that this is=20
> already possible with some SPV implementations, but to have the=20
> functionality directly in Core would make this BIP more viable.
>
> >=C2=A0That being said, BIP322 as-is has already been adopted by at least=
=20
> some wallets, despite its unfinished state. So if someone were to pick=20
> up this task, it would probably need to be done as a new BIP
>
> Probably the best solution would be to make a split, where the BIP322=20
> draft as it currently is can be used unofficially and then programmed=20
> into software that needs it, and then you can have the actual=20
> authentication/contract mechanism constructed in a new BIP. Actually,=20
> we already have some of the framework for this in Core, since PSBTs=20
> can be used to distribute and sign "message contracts". All that's=20
> needed is an RPC to get the UTXO set and another to create an unsigned=20
> template transaction for the message.
>
> -Ali
>
> On Saturday, May 4, 2024 at 12:14:53=E2=80=AFAM UTC Luke Dashjr wrote:
>
>     KYC is not an intended use case for signed messages, and attempts
>     to use it for that are probably one of the bigger reasons BIP322
>     has not moved further - most people do not want to encourage nor
>     enable such nonsense. If you absolutely must only allow withdrawls
>     to the user's own address, I would suggest taking a more
>     traditional approach of asking the user to affirm it with a
>     checkbox. (This is not legal advice, but it seems crazy to demand
>     cryptographic proof from Bitcoin companies, when traditional
>     finance is okay with a mere attestation)
>
>     Technically speaking, however, the biggest hurdle is that there is
>     very little apparent interest in the one limited use case it *is*
>     meant for: agreeing to a contract before funds are sent. To a
>     limited extent, a secondary use case has been simply using Bitcoin
>     addresses as a kind of login mechanism (eg, #Bitcoin-OTC and
>     OCEAN). But the feature with much higher demand is proof-of-funds
>     and proof-of-sender, which BIP322 began to address, but turns out
>     to be much more complicated than it seems at face value (I
>     recently looked into this again as part of relaunching OCEAN).
>     That being said, BIP322 as-is has already been adopted by at least
>     some wallets, despite its unfinished state. So if someone were to
>     pick up this task, it would probably need to be done as a new BIP. :/
>
>     Luke
>
>
>     On 5/3/24 19:53, ProfEduStream wrote:
>>
>>     Hey,
>>
>>     As a Bitcoin association, we're currently facing an issue because
>>     we're unable to sign an address with our multi-sig wallet.
>>     After conducting some research, I came across BIP322 in these
>>     threads:https://bitcointalk.org/index.php?topic=3D5408898.0 &
>>     https://github.com/bitcoin/bips/pull/1347
>>
>>     _Explanation_:
>>
>>     As a Bitcoin association, we offer membership to everyone for a
>>     few thousand sats per year. To facilitate this process, we
>>     utilize "Swiss Bitcoin Pay". It's an application that allows us
>>     to easily manage our accounting. Additionally, we onboard
>>     merchants with this app because of its user-friendly interface
>>     and self-custodial capabilities, making it very convenient. The
>>     accounting features are also highly beneficial.
>>
>>     To utilize this application in a self-custodial manner, users
>>     need to paste a Bitcoin address on the "Swiss Bitcoin Pay"
>>     dashboard and then sign a message with this address. This serves
>>     as a "Proof-of-Ownership" and is a legal requirement in some
>>     regulated countries. "Swiss Bitcoin Pay" is not the only
>>     application that requires signing a message as a
>>     "Proof-of-Ownership". Peach, a non-KYC P2P Bitcoin application,
>>     is another example.
>>
>>     Given our goal to decentralize our treasury, we naturally opt for
>>     a multi-sig wallet, similar to many companies. However, as you
>>     know, BIP 322 hasn't been pushed and it's currently impossible to
>>     sign a message with a multi-sig wallet.
>>
>>
>>     _Conclusion_:
>>
>>     I'm unsure why BIP322 hasn't been pushed or addressed in the past
>>     few months/years, but I want to highlight its necessity.
>>     Additionally, I hope that this comment sheds light on a
>>     deficiency in our Bitcoin ecosystem, and I trust that further
>>     improvements will be made to enable people to sign a message with
>>     a multi-sig wallet.
>>
>>
>>     I'm available to assist if needed.
>>
>>     @ProfEduStream
>>
>>     --=20
>>     You received this message because you are subscribed to the
>>     Google Groups "Bitcoin Development Mailing List" group.
>>     To unsubscribe from this group and stop receiving emails from it,
>>     send an email to bitcoindev+...@googlegroups.com.
>>     To view this discussion on the web visit
>>     https://groups.google.com/d/msgid/bitcoindev/9004c5d4-6b9d-4ac1-834c=
-902ba4901e05n%40googlegroups.com
>>     <https://groups.google.com/d/msgid/bitcoindev/9004c5d4-6b9d-4ac1-834=
c-902ba4901e05n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>.
>
> --=20
> You received this message because you are subscribed to the Google=20
> Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send=20
> an email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion on the web visit=20
> https://groups.google.com/d/msgid/bitcoindev/5fcc4168-b4fd-4efd-b11c-6bbf=
852871ccn%40googlegroups.com=20
> <https://groups.google.com/d/msgid/bitcoindev/5fcc4168-b4fd-4efd-b11c-6bb=
f852871ccn%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>.

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/b7861fc2-d980-4c3a-a472-ea7aead01692%40dashjr.org.

--------------Aujo0o2M0Gz3kQf5GKwVZcPV
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-8=
">
  </head>
  <body>
    <p>Addresses are not tied to UTXOs. A proof-of-funds would only ever
      be proving a numeric amount, not an address. While the proof would
      necessarily use UTXOs behind-the-scenes, the signature would not
      be committing to those specific UTXOs being the property of the
      message-signer; this property is necessary for plausible
      deniability as well as hot/cold wallet separation (multiple users
      could have signed messages using the same UTXOs, yet reflecting
      distinct bitcoin claims).</p>
    <p>Proof-of-sender, on the other hand, would make a claim to have
      sent a specific txid and output index. Where this gets fairly
      complicated is that it's somewhat important to have a mechanism
      that is compatible with coinjoins, and without requiring the
      coinjoin participants to keep in contact after the transaction is
      formed. It should able be compatible with signing for transactions
      sent without preparation to sign messages later. Ultimately, this
      requires delegation.</p>
    <p>And since it wouldn't be great to be able to distinguish between
      delegated and non-delegated, probably everything should just
      always be delegated (perhaps to a deterministic keypair in some
      scenarios).</p>
    <p>There's also potentially a use case for accepting an opcode
      rejects on mainnet as invalid, so tapscripts can commit to
      sign-only script paths.</p>
    <p>One thing all the current message signing standards lack is some
      kind of magic heading to identify what they are, like bech32's
      "bc1" prefix. This would be a trivial addition rather than trying
      to decode signatures N different ways and seeing which verify.</p>
    <p>I do agree being able to, at least internally, convert to/from
      PSBTs would improve compatibility significantly. This was the
      approach I aimed for when I tried to tackle it a few months ago.
      One limitation with PSBTs is that each input needs non-witness
      and/or witness input data - repeatedly, if multiple of the same
      transaction's outputs are used as inputs. To address that, I was
      planning to support having them refer back to previous inputs'
      data.</p>
    <p>Hope all this helps, if someone wants to pick up the task...</p>
    <p>Luke<br>
    </p>
    <div class=3D"moz-cite-prefix">On 5/5/24 08:09, Ali Sherief wrote:<br>
    </div>
    <blockquote type=3D"cite"
      cite=3D"mid:5fcc4168-b4fd-4efd-b11c-6bbf852871ccn@googlegroups.com">
      <div>&gt;=C2=A0But the feature with much higher demand is
        proof-of-funds and proof-of-sender, which BIP322 began to
        address, but turns out to be much more complicated than it seems
        at face value (I recently looked into this again as part of
        relaunching OCEAN).</div>
      <div><br>
      </div>
      <div>BIP322 is trying to figure two things: Collecting an
        authentic UTXO set for a given list of addresses, and actually
        making the signed message. It appears that only the latter of
        the two has been solved.</div>
      <div><br>
      </div>
      <div>I think one of the things that would help unstuck this is an
        RPC for getting the UTXO set of a list of addresses. I am aware
        that this is already possible with some SPV implementations, but
        to have the functionality directly in Core would make this BIP
        more viable.</div>
      <div><br>
      </div>
      &gt;=C2=A0That being said, BIP322 as-is has already been adopted by a=
t
      least some wallets, despite its unfinished state. So if someone
      were to pick up this task, it would probably need to be done as a
      new BIP
      <div><br>
      </div>
      <div>Probably the best solution would be to make a split, where
        the BIP322 draft as it currently is can be used unofficially and
        then programmed into software that needs it, and then you can
        have the actual authentication/contract mechanism constructed in
        a new BIP. Actually, we already have some of the framework for
        this in Core, since PSBTs can be used to distribute and sign
        "message contracts". All that's needed is an RPC to get the UTXO
        set and another to create an unsigned template transaction for
        the message.</div>
      <div><br>
      </div>
      <div>-Ali<br>
        <br>
        <div>
          <div dir=3D"auto">On Saturday, May 4, 2024 at 12:14:53=E2=80=AFAM=
 UTC
            Luke Dashjr wrote:<br>
          </div>
          <blockquote>
            <div>
              <p>KYC is not an intended use case for signed messages,
                and attempts to use it for that are probably one of the
                bigger reasons BIP322 has not moved further - most
                people do not want to encourage nor enable such
                nonsense. If you absolutely must only allow withdrawls
                to the user's own address, I would suggest taking a more
                traditional approach of asking the user to affirm it
                with a checkbox. (This is not legal advice, but it seems
                crazy to demand cryptographic proof from Bitcoin
                companies, when traditional finance is okay with a mere
                attestation)<br>
              </p>
              <p>Technically speaking, however, the biggest hurdle is
                that there is very little apparent interest in the one
                limited use case it *is* meant for: agreeing to a
                contract before funds are sent. To a limited extent, a
                secondary use case has been simply using Bitcoin
                addresses as a kind of login mechanism (eg, #Bitcoin-OTC
                and OCEAN). But the feature with much higher demand is
                proof-of-funds and proof-of-sender, which BIP322 began
                to address, but turns out to be much more complicated
                than it seems at face value (I recently looked into this
                again as part of relaunching OCEAN). That being said,
                BIP322 as-is has already been adopted by at least some
                wallets, despite its unfinished state. So if someone
                were to pick up this task, it would probably need to be
                done as a new BIP. :/<br>
              </p>
              <p>Luke</p>
            </div>
            <div>
              <p><br>
              </p>
              <div>On 5/3/24 19:53, ProfEduStream wrote:<br>
              </div>
            </div>
            <div>
              <blockquote type=3D"cite">
                <p dir=3D"auto">Hey,</p>
                <p dir=3D"auto">As a Bitcoin association, we're currently
                  facing an issue because we're unable to sign an
                  address with our multi-sig wallet.<br>
                  After conducting some research, I came across BIP322
                  in these threads:<span> </span><a
href=3D"https://bitcointalk.org/index.php?topic=3D5408898.0" target=3D"_bla=
nk"
                    rel=3D"nofollow" moz-do-not-send=3D"true"
                    class=3D"moz-txt-link-freetext">https://bitcointalk.org=
/index.php?topic=3D5408898.0</a>
                  &amp; <a
                    href=3D"https://github.com/bitcoin/bips/pull/1347"
                    target=3D"_blank" rel=3D"nofollow"
                    moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext=
">https://github.com/bitcoin/bips/pull/1347</a><br>
                  <br>
                </p>
                <p dir=3D"auto"><u>Explanation</u>:</p>
                <p dir=3D"auto">As a Bitcoin association, we offer
                  membership to everyone for a few thousand sats per
                  year. To facilitate this process, we utilize "Swiss
                  Bitcoin Pay". It's an application that allows us to
                  easily manage our accounting. Additionally, we onboard
                  merchants with this app because of its user-friendly
                  interface and self-custodial capabilities, making it
                  very convenient. The accounting features are also
                  highly beneficial.</p>
                <p dir=3D"auto">To utilize this application in a
                  self-custodial manner, users need to paste a Bitcoin
                  address on the "Swiss Bitcoin Pay" dashboard and then
                  sign a message with this address. This serves as a
                  "Proof-of-Ownership" and is a legal requirement in
                  some regulated countries. "Swiss Bitcoin Pay" is not
                  the only application that requires signing a message
                  as a "Proof-of-Ownership". Peach, a non-KYC P2P
                  Bitcoin application, is another example.</p>
                <p dir=3D"auto">Given our goal to decentralize our
                  treasury, we naturally opt for a multi-sig wallet,
                  similar to many companies. However, as you know, BIP
                  322 hasn't been pushed and it's currently impossible
                  to sign a message with a multi-sig wallet.</p>
                <p dir=3D"auto"><br>
                </p>
                <p dir=3D"auto"><u>Conclusion</u>:</p>
                <p dir=3D"auto">I'm unsure why BIP322 hasn't been pushed
                  or addressed in the past few months/years, but I want
                  to highlight its necessity.<br>
                  Additionally, I hope that this comment sheds light on
                  a deficiency in our Bitcoin ecosystem, and I trust
                  that further improvements will be made to enable
                  people to sign a message with a multi-sig wallet.</p>
                <p dir=3D"auto"><br>
                </p>
                <p dir=3D"auto">I'm available to assist if needed<span>.</s=
pan></p>
                <p dir=3D"auto"><span>@ProfEduStream<br>
                  </span></p>
              </blockquote>
            </div>
            <div>
              <blockquote type=3D"cite"> -- <br>
                You received this message because you are subscribed to
                the Google Groups "Bitcoin Development Mailing List"
                group.<br>
                To unsubscribe from this group and stop receiving emails
                from it, send an email to <a rel=3D"nofollow"
                  moz-do-not-send=3D"true">bitcoindev+...@googlegroups.com<=
/a>.<br>
                To view this discussion on the web visit <a
href=3D"https://groups.google.com/d/msgid/bitcoindev/9004c5d4-6b9d-4ac1-834=
c-902ba4901e05n%40googlegroups.com?utm_medium=3Demail&amp;utm_source=3Dfoot=
er"
                  target=3D"_blank" rel=3D"nofollow" moz-do-not-send=3D"tru=
e">https://groups.google.com/d/msgid/bitcoindev/9004c5d4-6b9d-4ac1-834c-902=
ba4901e05n%40googlegroups.com</a>.<br>
              </blockquote>
            </div>
          </blockquote>
          <div>=C2=A0</div>
        </div>
      </div>
      -- <br>
      You received this message because you are subscribed to the Google
      Groups "Bitcoin Development Mailing List" group.<br>
      To unsubscribe from this group and stop receiving emails from it,
      send an email to <a
        href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com"
        moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext">bitcoindev=
+unsubscribe@googlegroups.com</a>.<br>
      To view this discussion on the web visit <a
href=3D"https://groups.google.com/d/msgid/bitcoindev/5fcc4168-b4fd-4efd-b11=
c-6bbf852871ccn%40googlegroups.com?utm_medium=3Demail&amp;utm_source=3Dfoot=
er"
        moz-do-not-send=3D"true">https://groups.google.com/d/msgid/bitcoind=
ev/5fcc4168-b4fd-4efd-b11c-6bbf852871ccn%40googlegroups.com</a>.<br>
    </blockquote>
  </body>
</html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/b7861fc2-d980-4c3a-a472-ea7aead01692%40dashjr.org?utm=
_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitc=
oindev/b7861fc2-d980-4c3a-a472-ea7aead01692%40dashjr.org</a>.<br />

--------------Aujo0o2M0Gz3kQf5GKwVZcPV--