<unnamed>

Public Key

npub1qvg3k0w2c3ggh4wumg3pkzetfeqe9y4wgq7x5aaxz4ypjvap9vksr9t9zs

Profile Code

nprofile1qqsqxygm8h9vg5yt6hwd5gsmpv45usvjj2hyq0r2w7np2jqexwsjktgpz4mhxue69uhhyetvv9ujumn0wd68ytnwv46qz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mqzn9m0j

Publishing to

relay.nostr.net

relay.damus.io

nos.lol

Last Notes

2023-06-08 01:13:02 CEST

- reply

📅 Original date posted:2022-08-25
📝 Original message: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 derivation from seed, which
means wallets functioning as coordinators cannot use the format without
access to the devices storing the private keys. It seems to me that wallet
labels are more privacy rather than security sensitive, and coordinators
should be able to import and export a wallet label format independently.
Secondly, it uses JSON as a data format, which I wanted to avoid for
reasons I'll describe in a separate reply in this thread. Finally (and this
is minor as it could easily be extended) SLIP-0015 does not currently
support transaction labels.
Craig
On Wed, Aug 24, 2022 at 3:53 PM Clark Moody <clark at clarkmoody.com> wrote:
> 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, August 24th, 2022 at 4:18 AM, Craig Raw via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> 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
>
> ---
>
> <pre>
> BIP: wallet-labels
> Layer: Applications
> Title: Wallet Labels Export Format
> Author: Craig Raw <craig at sparrowwallet.com>
> 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
> </pre>
>
> ==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 not present a problem.
> Moreover, the simplicity and forgiving nature of CSV (over for example
> JSON) lends itself well to bulk label editing using spreadsheet and text
> editing tools.
>
> A CSV export of labels from a wallet must be a UTF-8 encoded text file,
> containing one record per line, with records containing two fields
> delimited by a comma.
> The fields may be quoted, but this is unnecessary, as the first comma in
> the line will always be the delimiter.
> The first line in the file is a header, and should be ignored on import.
> Thereafter, each line represents a record that refers to a label applied
> in the wallet.
> The order in which these records appear is not defined.
>
> The first field in the record contains a reference to the transaction,
> address, input or output in the wallet.
> This is specified as one of the following:
> * Transaction ID (<tt>txid</tt>)
> * Address
> * Input (rendered as <tt>txid<index</tt>)
> * Output (rendered as <tt>txid>index</tt> or <tt>txid:index</tt>)
>
> The second field contains the label applied to the reference.
> Exporting applications may omit records with no labels or labels of zero
> length.
> Files exported should use the <tt>.csv</tt> file extension.
>
> In order to reduce file size while retaining wide accessibility, the CSV
> file may be compressed using the ZIP file format, using the <tt>.zip</tt>
> file extension.
> This <tt>.zip</tt> file may optionally be encrypted using either AES-128
> or AES-256 encryption, which is supported by numerous applications
> including Winzip and 7-zip.
> In order to ensure that weak encryption does not proliferate, importers
> following this standard must refuse to import <tt>.zip</tt> files encrypted
> with the weaker Zip 2.0 standard.
> The textual representation of the wallet's extended public key (as defined
> by BIP32, with an <tt>xpub</tt> header) should be used as the password.
>
> ==Importing==
>
> When importing, a naive algorithm may simply match against any reference,
> but it is possible to disambiguate between transactions, addresses, inputs
> and outputs.
> For example in the following pseudocode:
> <pre>
> if reference length < 64
> Set address label
> else if reference length == 64
> Set transaction label
> else if reference contains '<'
> Set input label
> else
> Set output label
> </pre>
>
> Importing applications may truncate labels if necessary.
>
> ==Test Vectors==
>
> The following fragment represents a wallet label export:
> <pre>
> Reference,Label
>
> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎,Transaction
> 1A69TXnEM2ms9fMaY9UuiJ7415X7xZaUSg,Address
> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎<0,Input
> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎>0,Output
> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎:0,Output
> (alternative)
> </pre>
>
> ==Reference Implementation==
>
> TBD
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220825/acdd8972/attachment-0001.html>

2023-06-08 01:11:58 CEST

- reply

📅 Original date posted:2022-07-21
📝 Original message:> Unfortunately, I do not know of any "verifiers" that will accept the
above signature
Sparrow verifies this signature.
The approach used is to convert the message and signature to a public key,
trying first BIP137 and then the approach used by Electrum (they differ in
treatment of the signature header for segwit P2SH). The script type is
extracted from the provided address and compared against the address
constructed with the public key using the same script type. i.e. There is
no need to iterate through all script types, since the script type is
implicitly provided in the address.
Craig
On Wed, Jul 20, 2022 at 11:51 PM Greg Sanders via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Please see BIP322
> https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki
>
> On Wed, Jul 20, 2022, 5:46 PM Peter (Coinkite Inc) via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi Ali.
>>
>> > This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My
>> proposal is simply going to standardize the practice of placing the segwit
>> address into the address field, and does not require alterations to the
>> message signing format like those BIPs.
>>
>> COLDCARD makes signatures exacly like that, when told to sign with a
>> segwit address:
>>
>> % ckcc msg -s Hello
>> Hello
>> bc1qzeacswvlulg0jngad9gmtkvdp9lwum42wwzdu5
>>
>> HxuuWQwjw0417fLV9L0kWbt7w9XOIWKhHMhjXhyXTczcSozGTXM4knqdISiYbbmqSRXqI5mNTWH9qkDoqZTpnPc=
>>
>> Unfortunately, I do not know of any "verifiers" that will accept the
>> above signature, but there is no alternative since the various BIP-322
>> proposals never gained wide acceptance.
>>
>> Bitcoin Core does not support verifying that message, even though the UX
>> makes it look possible. In effect segwit features never got implemented to
>> that depth in Core. It's sad because the community is not maintaining core
>> (Core?) features to the same depth as Satoshi did when he was active in the
>> project.
>>
>> > PS. I am pretty sure that there is a BIP for the original signing
>> method - what is its number?
>>
>> My understanding that the original approach was directly from Satoshi
>> himself when the original client was written. It has never been codified in
>> a BIP as far as I know.
>>
>> A related issue the the "ascii armor" that is sometimes used. It's a
>> little like RFC2440 <https://www.ietf.org/rfc/rfc2440.txt> but
>> newline-treatment isn't defined well enough for good interoperability, in
>> my personal experience.
>>
>> So in summary... yes a "defacto" BIP is needed and useful to do, in my
>> opinion. Then Core should be updated to support it as well.
>>
>> ---
>> @DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10
>>
>>
>> On Wed, Jul 20, 2022 at 04:10:09AM +0000, Ali Sherief wrote:
>> > [my third attempt at getting this message through. Surprisingly, I
>> managed to send this at the second try with the correct SMTP, From, To and
>> all, but maybe it was caught in GreyListing (protonmail).]
>> >
>> > I was thinking about creating a BIP to address the lack of
>> standardization for Segwit message signatures, but I want some advice
>> before proceeding.
>> >
>> > The current state of affairs is that the wallets that do support
>> signing and verifying a bitcoin message can only sign legacy addresses. It
>> is technically possible to sign and verify segwit addresses, since ECDSA
>> only depends on the public key (hence why you need a private key to sign
>> messages).
>> >
>> > However, because there is no generally-accepted standard for signing
>> segwit messages, the wallets that do support this feature simply insert the
>> segwit address into the address field. Verification also only works using
>> the procedure on that specific wallet software, if only because the
>> conventional tools for verifying messages attempt to reconstruct a legacy
>> address only.
>> >
>> > This BIP is not going to enforce anything, it's just going to set
>> guidelines for writing a message signing and verification procedure.
>> >
>> > This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My
>> proposal is simply going to standardize the practice of placing the segwit
>> address into the address field, and does not require alterations to the
>> message signing format like those BIPs.
>> >
>> > In summary, in the verification part, the following address hashing
>> algorithms will be tried in sequence in an attempt to reconstruct the
>> address in the signed message:
>> > - P2PKH (legacy address)
>> > - P2WPKH-P2SH (nested segwit)
>> > - P2WPKH with version from 0 to MAX_WITNESS_VERSION (covers native
>> segwit with version 0 as well as future native segwit address types such as
>> Taproot) - where MAX_WITNESS_VERSION is the maximum supported witness
>> version by the bech32 encoding.
>> >
>> > The verification procedure stops if any of these hashes yield the
>> correct address, and fails if all of the above methods fail to reproduce
>> the address in the signed message.
>> >
>> > In the signing procedure, the only modification is the insertion of the
>> segwit address in place of the legacy address in the signed message.
>> >
>> > If this BIP is approved, it does not require any changes to existing
>> signed messages, and the original sign/verify algorithms will continue to
>> interoperate with this improved sign/verify algorithm, without any action
>> necessary from the developers.
>> >
>> > So as you can see, this is the entire framework of the BIP I plan to
>> draft. There is no need for any auxilliary feature additions into this BIP.
>> I just want to hear the mailing list's advice about how I should draft such
>> a BIP.
>> >
>> > - Ali
>> >
>> > PS. I am pretty sure that there is a BIP for the original signing
>> method - what is its number?
>> >
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220721/8ad06d81/attachment.html>

2023-06-07 20:30:44 CEST

- reply

📅 Original date posted:2021-03-17
📝 Original message:The motivation for this BIP proposal states that encoding the script type
in the derivation is redundant because output descriptors are becoming
commonplace. However, I think it's important to note that this shifts more
burden of wallet backup onto the user, who now has an additional item (the
output descriptor) to backup correctly. This is particularly important when
we consider that performing this backup is often laborious, including
stamping onto metal etc.
There are two ways to go here:
1. Use derivation paths that do not encode the script type, and conduct a
global education effort to encourage users to backup output descriptors in
addition to their seed words, without which their funds may be lost.
2. Use a standard set of derivation paths that encode the script type,
ensuring that even if users do not back this up, they can check against a
handful of common derivations and recover the funds.
Option 1 is obviously cleaner and more precise from a technical POV, but I
feel it is less practical. The approach of using common words to encode the
seed was chosen because these words are short and familiar - an output
descriptor on the other hand is technical and longer form, and thus more
difficult to record correctly, particularly on damage-resistant media.
Craig
On Tue, Mar 16, 2021 at 2:19 PM Robert Spigler via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> No, wallets don't and shouldn't have to check all script types on
> recovery. Descriptor Wallets solve all of this.
>
> To back up a multisignature wallet, each cosigner stores their xprv (how
> you do this; BIP39, WIF, etc, is out of scope). and the wallet descriptor.
> This is done, for example, in Yeti. To recover, simply combine `M` private
> keys, and check the script designated in 1 of the descriptor copies.
>
> For single signature wallets, it is the same, except only one signature is
> needed. Store xprv and descriptor.
>
> It is not fair nor accurate to say that currently, in order to recover,
> wallets need "just the seed words". They also need all public keys, and
> derivation paths.
>
> Descriptors (and this BIP), is a much cleaner way to handle wallet
> creation and backup, by separating the two layers (keys and scripts) and
> getting rid of redundant information.
>
>
> Personal Fingerprint: BF0D 3C08 A439 5AC6 11C1 5395 B70B 4A77 F850 548F
>
>
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Sunday, March 14, 2021 11:13 AM, SomberNight <
> somber.night at protonmail.com> wrote:
>
> > See some replies inline. (quoted text from BIP draft)
> >
> > > Date: Sun, 14 Mar 2021 01:51:15 +0000
> > > From: Robert Spigler RobertSpigler at protonmail.ch
> > > Subject: [bitcoin-dev] Signature and Script Independent Hierarchy for
> Deterministic Wallets.
> >
> > > There are many issues with the current standards. As background, BIP
> 44/49/84 specifies:
> > > `m / purpose' / coin_type' / account' / change / address_index`
> > > where the BIP43 `purpose'` path is separate for each script (P2PKH,
> P2WPKH-in-P2SH, and P2WPKH respectively). However, these per-script
> derivations are made redundant with descriptors
> >
> > > We should not be mixing keys and scripts in the same layer. The wallet
> should create extended private/public keys independent of the script or
> signature type
> >
> > You say that keys and scripts should not be mixed in the same layer, and
> imply that this was solely done due to these standards predating output
> script descriptors. Even if this was the case, it is not the only reason
> for doing it. BIP44/49/84 mixing scripts and keys in the same layer makes
> recovery from seed/mnemonic much easier.
> > Note the significant overlap between the authors of BIP39 and BIP44. I
> am fairly certain BIP44 was designed with recovering from a BIP39 seed (and
> no additional information backed up) in mind. Note the "Account discovery"
> section of BIP44.
> > (Electrum seeds go even further, as such seeds contain a version number
> that encodes both the script type and the key derivation path to use.)
> >
> > > We define the following 5 levels in the BIP32 path:
> > > `m / purpose' / coin_type' / account' / change / address_index`
> >
> > > [Account]
> > > It is crucial that this level is increased for each new wallet joined
> or private/public keys created; for both privacy and cryptographic purposes.
> > > For example, in multisignature wallets, before sending a new key
> record to a coordinator, the wallet must increment the `account'` level.
> Before creating it's own single signature wallet, the `account'` level must
> again be incremented.
> >
> > Imagine a user who has a BIP39 (or similar) seed. Even today, recovering
> most non-singlesig scripts from that is obviously infeasible. However, all
> singlesig scripts at least can be discovered if the keys are using the
> suggested derivation paths.
> > By trying to create a standard that mixes discoverable and
> non-discoverable scripts in the same derivation scheme and incrementing a
> single index, you are turning all scripts into being non-discoverable.
> > Note that even if a user only used singlesig scripts and followed this
> proposal, during recovery from seed the wallet would have to check all
> script types for all account indices (which is only ever going to get more
> expensive as new script types come).
> > The workaround and I imagine your suggested solution is clearly to
> backup both seed words and output script descriptors; and to keep appending
> new output script descriptors to existing backups when the account index is
> incremented. While much less user-friendly than backing up just a seed, it
> is more generic and extendable.
> >
> > My point is simply that your proposal is making a tradeoff here. The
> tradeoff itself seems easy to miss on first read of the text, so I just
> wanted to explicitly point it out for the record.
> >
> > ghost43 / SomberNight
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210317/5587c0ec/attachment.html>

2023-06-07 20:29:39 CEST

- reply

📅 Original date posted:2021-03-01
📝 Original message:Something to consider adding to this proposal is to keep the idea of
pruning - i.e. retain a sequentially uninterrupted number of the most
recent blocks.
Many users do not run a node for entirely altruistic reasons - they do so,
at least in part, because it allows them to use their wallets privately.
Without this ability, I think the number of users willing to run their node
in this configuration might be reduced.
Another related thought is to have a decreasing density over blocks over
time as you go backwards towards genesis, in order for the data density of
the storage to match the actual usage of the network, in which (I would
imagine) more recent blocks are more heavily requested than early ones.
Craig
On Sun, Feb 28, 2021 at 10:18 AM Leo Wandersleb via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Only headers need to be downloaded sequentially so downloading relevant
> blocks
> from one node is totally possible with gaps in between.
>
> On 2/27/21 4:10 AM, Igor Cota via bitcoin-dev wrote:
> > Hi Keagan,
> >
> > I had a very similar idea. The only difference being for the node to
> decide on
> > a range of blocks to keep beforehand, rather than making the decision
> > block-by-block like you suggest.
> >
> > I felt the other nodes would be better served by ranges due to the
> sequential
> > nature of IBD. Perhaps this would be computationally lighter as well.
> >
> > I also encourage you to read Ryosuke Abe's paper [1] that proposes a DHT
> > scheme to solve this same problem.
> >
> > Cheers,
> > Igor
> >
> > [1] https://arxiv.org/abs/1902.02174
> >
> > On Fri, 26 Feb 2021 at 21:57, Keagan McClelland via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org
> > <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> >
> > Hi all,
> >
> > I've been thinking for quite some time about the problem of pruned
> nodes
> > and ongoing storage costs for full nodes. One of the things that
> strikes
> > me as odd is that we only really have two settings.
> >
> > A. Prune everything except the most recent blocks, down to the cache
> size
> > B. Keep everything since genesis
> >
> > From my observations and conversations with various folks in the
> > community, they would like to be able to run a "partially" pruned
> node to
> > help bear the load of bootstrapping other nodes and helping with data
> > redundancy in the network, but would prefer to not dedicate hundreds
> of
> > Gigabytes of storage space to the cause.
> >
> > This led me to the idea that a node could randomly prune some of the
> > blocks from history if it passed some predicate. A rough sketch of
> this
> > would look as follows.
> >
> > 1. At node startup, it would generate a random seed, this would be
> unique
> > to the node but not necessary that it be cryptographically secure.
> > 2. In the node configuration it would also carry a "threshold"
> expressed
> > as some percentage of blocks it wanted to keep.
> > 3. As IBD occurs, based off of the threshold, the block hash, and the
> > node's unique seed, the node would either decide to prune the data
> or keep
> > it. The uniqueness of the node's hash should ensure that no block is
> > systematically overrepresented in the set of nodes choosing this
> storage
> > scheme.
> > 4. Once the node's IBD is complete it would advertise this as a peer
> > service, advertising its seed and threshold, so that nodes could
> > deterministically deduce which of its peers had which blocks.
> >
> > The goals are to increase data redundancy in a way that more
> uniformly
> > shares the load across nodes, alleviating some of the pressure of
> full
> > archive nodes on the IBD problem. I am working on a draft BIP for
> this
> > proposal but figured I would submit it as a high level idea in case
> anyone
> > had any feedback on the initial design before I go into specification
> > levels of detail.
> >
> > If you have thoughts on
> >
> > A. The protocol design itself
> > B. The barriers to put this kind of functionality into Core
> >
> > I would love to hear from you,
> >
> > Cheers,
> > Keagan
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
> >
> > --
> > *Igor Cota*
> > Codex Apertus d.o.o.
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210301/57cba055/attachment-0001.html>

2023-06-07 20:28:39 CEST

- reply

📅 Original date posted:2021-02-15
📝 Original message:Hi all,
Hugo and I have discussed off-list, and I have two concerns with this
proposal:
1. I believe adding the TOKEN and encryption to the exchange adds
complexity to already notoriously complex multisig, without adding much in
the way of security. This is because the shared secret (TOKEN) must still
be shared securely, and if you have established an (off-protocol) secure
channel to do this, why not just share the actual multisig configuration
data directly in that channel? If you are able to do so, you retain the
advantage of being able to inspect the data directly.
2. Asking the user to enter the derivation into the Signer also adds (IMO
unnecessary) complexity to the multisig setup process. A different way of
doing it, which is specified in the UR crypto-account format linked to
previously, has the Signer provide as many common derivations (along with
their xpubs) as it can support for a given BIP44 account number. This has
the dual advantage of making things simpler for the user (they only have to
provide an optional account number) and increasing the standardisation on
common derivation paths. On receiving these derivation/xpub pairs, the
Coordinator can simply pick the appropriate one.
These concerns noted, I agree it's a good idea to have Signers save the
multisig configuration as proposed, and it would be great to have
standardisation in hww import and export formats (not just for multisig).
On that note, I'd love to see greater adoption of the efficient UR2.0
standard and associated formats for airgapped data transmission using QR
codes.
Craig
On Mon, Feb 15, 2021 at 11:13 AM Hugo Nguyen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all,
> I have updated the proposal based on further feedback. The new spec is
> included at the bottom.
>
> I have also created a public Github PR to make it easier to comment on the
> text of the spec itself: https://github.com/nunchuk-io/bips/pull/1 .
>
> Could someone please let me know what else needs to be done before a BIP
> number can be assigned?
>
>
> === Quick summary of changes from last update ===
>
> 1. Define encryption modes
>
> # NO_ENCRYPTION: Encryption is disabled.
> # STANDARD : the TOKEN is a 64-bit nonce.
> # EXTENDED : the TOKEN is a 128-bit nonce.
>
> 2. Define signature algorithm
>
> Follow BIP-0322, legacy format allowed.
>
> 3. Multiple TOKENs (optional)
>
> Also add an option where the Coordinator can choose to use one common
> TOKEN for all Signers, or use one per Signer.
>
> === End of summary ===
>
>
> Cheers,
> Hugo
>
>
> <pre>
> BIP: To be determined
> Layer: Applications
> Title: Bitcoin Secure Multisig Setup (BSMS)
> Author: Hugo Nguyen <hugo at nunchuk.io>, Peter Gray <peter at
> coinkite.com>, Marko Bencun <marko at shiftcrypto.ch>, Pavol Rusnak <
> stick at satoshilabs.com>, Aaron Chen <aarondongchen at gmail.com>, Rodolfo
> Novak <rodolfo at coinkite.com>
> Comments-Summary: No comments yet.
> Comments-URI:
> Status: Proposed
> Type: Standards Track
> Created: 2020-11-10
> License: BSD-2-Clause
> </pre>
>
> ==Introduction==
>
> ===Abstract===
>
> This document proposes a mechanism to set up multisig wallets securely.
>
> ===Copyright===
>
> This BIP is licensed under the 2-clause BSD license.
>
> ===Motivation===
>
> The Bitcoin multisig experience has been greatly streamlined under [
> https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki BIP-0174
> (Partially Signed Bitcoin Transaction)]. However, what is still missing is
> a standardized process for setting up multisig wallets securely across
> different vendors.
>
> There are a number of concerns when it comes to setting up a multisig
> wallet:
>
> # Whether the multisig configuration, such as Signer membership, script
> type, derivation paths and number of signatures required, is correct and
> not tampered with.
> # Whether Signer persists the multisig configuration in their respective
> storage, and under what format.
> # Whether Signer's storage is tamper-proof.
> # Whether Signer subsequently uses the multisig configuration to generate
> and verify receive and change addresses.
>
> An attacker who can modify the multisig configuration can steal or hold
> funds to ransom by duping the user into sending funds to the wrong address.
>
> This proposal seeks to address concerns #1 and #2: to mitigate the risk of
> tampering during the initial setup phase, and to define an interoperable
> multisig configuration format.
>
> Concerns #3 and #4 should be handled by Signers and is out of scope of
> this proposal.
>
> ==Specification==
>
> ===Prerequisites===
> This proposal assumes the parties in the multisig support [
> https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-0032],
> [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the
> descriptor language] and encryption.
>
> ===Roles===
> ====Coordinator====
>
> The Coordinator initiates the multisig setup. The Coordinator determines
> what type of multisig is used and the exact policy script. If encryption is
> enabled, the Coordinator also distributes a shared secret or shared secrets
> to the parties involved for secure communication. The Coordinator gathers
> information from the Signers to generate a descriptor record. The
> Coordinator distributes the descriptor record back to the Signers.
>
> ====Signer====
>
> The Signer is a participating member in the multisig. Its responsibilities
> include providing its key record -- which contains an Extended Public Key
> (XPUB) -- to the Coordinator, verifying that its XPUB is included in the
> descriptor record and persisting the descriptor record in its storage.
>
> ===Setup Process===
>
> ====Round 1====
>
> =====Coordinator=====
>
> * The Coordinator creates a multisig wallet creation session. The
> Coordinator constructs the multisig script and its policy parameters, such
> as the total number of signers and the required number of signatures
> (<tt>M</tt> and <tt>N</tt>).
> * The session should expire after some time period determined by the
> Coordinator, e.g., 24 hours.
> * If encryption is enabled, the Coordinator distributes a secret
> <tt>TOKEN</tt> to each Signer over a secure channel. The Signer can use the
> <tt>TOKEN</tt> to derive an <tt>ENCRYPTION_KEY</tt>. Refer to the
> Encryption section below for details on the <tt>TOKEN</tt>, the key
> derivation function and the encryption scheme. Depending on the use case,
> the Coordinator can decide whether to share one common <tt>TOKEN</tt> for
> all Signers, or to have one per Signer.
> * If encryption is disabled, <tt>TOKEN</tt> is set to <tt>0</tt>, and all
> the encryption/decryption steps below can be skipped.
>
> =====Signer=====
>
> * The Signer initiates a new secure multisig setup session by setting the
> <tt>TOKEN</tt>. The Signer derives an <tt>ENCRYPTION_KEY</tt> from the
> <tt>TOKEN</tt>. The Signer can keep the session open until a different
> value for the <tt>TOKEN</tt> is set.
> * The Signer generates a key record by prompting the user for a multisig
> derivation path and retrieves the XPUB at that derivation path. Optionally,
> the Signer can choose a path on behalf of the user. If the Signer chooses
> the path, it should try to avoid reusing XPUBs for different wallets.
> * The first line in the record must be the <tt>TOKEN</tt>. The second line
> must be the <tt>KEY</tt>. The <tt>KEY</tt> is an XPUB plus its key origin
> information, written in the descriptor-defined format, i.e.: <tt>[{master
> key fingerprint}/{derivation path}]{XPUB}</tt>. The third line must be a
> <tt>SIG</tt>, whereas <tt>SIG</tt> is the signature generated by using the
> private key associated with the XPUB to sign the first two lines. The
> signature should follow [
> https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki BIP-0322],
> legacy format accepted. Finally, the Signer encrypts the entire record with
> <tt>ENCRYPTION_KEY</tt>.
>
> ====Round 2====
>
> =====Coordinator=====
>
> * The Coordinator gathers key records from all participating Signers.
> Abort the setup if the wallet setup session has expired.
> * For each key record, the Coordinator decrypts it using
> <tt>ENCRYPTION_KEY</tt>. The Coordinator verifies that the included
> <tt>SIG</tt> is valid given the <tt>KEY</tt>.
> * If all key records look good, the Coordinator fills in all necessary
> information to generate a descriptor record, which is simply the descriptor
> string plus a <tt>CHECKSUM</tt>, all in one line. The <tt>CHECKSUM</tt> has
> [
> https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums
> BECH32 encoding].
> * The Coordinator encrypts this descriptor record with
> <tt>ENCRYPTION_KEY</tt>.
> * The Coordinator sends the encrypted descriptor record to all
> participating Signers.
>
> =====Signer=====
>
> * The Signer imports the descriptor record, decrypts it using the
> <tt>ENCRYPTION_KEY</tt> derived from the open session.
> * The Signer calculates and verifies the descriptor’s <tt>CHECKSUM</tt>.
> Abort the setup if the <tt>CHECKSUM</tt> is incorrect.
> * The Signer checks whether one of the <tt>KEY</tt>s in the descriptor
> belongs to it, using path and fingerprint information included in the
> descriptor. The check must perform an exact match on the <tt>KEY</tt>s, and
> not using shortcuts such as matching fingerprints (which is trivial to
> spoof). Abort the setup if it doesn’t detect its own <tt>KEY</tt>.
> * For confirmation, the Signer must display to the user the
> <tt>CHECKSUM</tt>, plus other configurations, such as <tt>M</tt> and
> <tt>N</tt>. The total number of Signers, <tt>N</tt>, is important to
> prevent a <tt>KEY</tt> insertion attack. All participating Signers should
> be able to display the same confirmation.
> * If all checks pass, the Signer persists the descriptor record in its
> storage.
> * The Signer can choose to further restrict post-XPUB derivation paths,
> such as to those defined in [
> https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki BIP-0044].
> * The Signer should subsequently use the descriptor to generate and verify
> receive and change addresses.
>
> This completes the setup.
>
> ===Encryption===
>
> ====The Token====
> We define three modes of encryption.
>
> # <tt>NO_ENCRYPTION</tt> : the <tt>TOKEN</tt> is set to <tt>0</tt>.
> Encryption is disabled.
> # <tt>STANDARD</tt> : the <tt>TOKEN</tt> is a 64-bit nonce.
> # <tt>EXTENDED</tt> : the <tt>TOKEN</tt> is a 128-bit nonce.
>
> The <tt>TOKEN</tt> can be converted to one of these formats:
> * A mnemonic phrase using [
> https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki BIP-0039]
> word list (6 words in <tt>STANDARD</tt> mode, 12 words in <tt>EXTENDED</tt>
> mode)
> * A decimal number (20 digits in <tt>STANDARD</tt> mode, 40 digits in
> <tt>EXTENDED</tt> mode)
> * A QR code
> * Other formats
>
> The flexibility in the data format allows each Signer to customize the
> User Experience based on its respective capabilities.
>
> ====Key Derivation====
> The key derivation function is [https://tools.ietf.org/html/rfc2898
> PBKDF2], with PRF = SHA512. Specifically:
>
> <tt>DK = PBKDF2(PRF, Password, Salt, c, dkLen)</tt>
>
> Whereas:
>
> * PRF = <tt>SHA512</tt>
> * Password = <tt>"No SPOF"</tt>
> * Salt = <tt>TOKEN</tt>
> * c = <tt>2048</tt>
> * dkLen = <tt>256</tt>
> * DK = Derived <tt>ENCRYPTION_KEY</tt>
>
> ====Encryption Scheme====
> The encryption scheme is [https://tools.ietf.org/html/rfc3686 AES, CTR
> mode].
>
> ==QR Codes==
> For signers that use QR codes to transmit data, key and descriptor records
> can be converted to QR codes, following [
> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md
> the BCR standard].
>
> Also refer to [
> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-015-account.md
> UR Type Definition for BIP44 Accounts] and [
> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-010-output-desc.md
> UR Type Definition for Bitcoin Output Descriptors] for more details.
>
> ==Security==
>
> This proposal introduces two layers of protection. The first one is a
> temporary, secret token, used to encrypt the two rounds of communication
> between the Signer and the Coordinator. The second one is through the
> descriptor checksum and visual inspection of the descriptor itself.
>
> The token is only needed during the setup phase, and can be safely thrown
> away afterwards. The token does not guarantee that the Signer membership
> set is not modified, since that depends on the overall security of all
> parties in the setup, but it can make it significantly harder for an
> attacker to do so.
>
> There are three ways an attacker can modify the membership set: by
> changing an existing member, by removing an existing member, or by adding a
> new member.
>
> For the first two methods, one of the Signers will be able to detect that
> its membership has been changed or removed, and reject the final
> descriptor. Thus, it is vital that all participating Signers check that
> their membership is intact in the descriptor. Even one Signer failing to
> check for its membership means that the setup could be compromised.
>
> For the third type of attack, the descriptor checksum and visual
> inspection of the descriptor itself are the only way to guard against
> malicious members from being inserted into the set.
>
> ==Acknowledgement==
>
> Special thanks to Dmitry Petukhov, Christopher Allen, Craig Raw and others
> for their feedback on the specification.
>
> ==References==
>
> Original mailing list thread:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018385.html
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210215/4ca65ae9/attachment-0001.html>

2023-06-07 20:28:31 CEST

- reply

📅 Original date posted:2021-02-09
📝 Original message:Hi Hugo,
Thanks for raising this again - I'll note there has already been much
discussion on this topic. With respect to your "two layers of protection":
> The Coordinator shares the TOKEN with all participating Signers over a
secure channel.
What secure channel do you propose? Currently, with the default of a
software wallet coordinator talking to hardware wallets, we have USB, file
(microSD), and QR as communication channels. It's unclear to me why the
token and encryption process is necessary - in fact it's easier to verify
what is going on using clear text, and the majority of setups will be
locally done with the reasonable assumption of a secure environment. When
the setup is remote, it's simpler to just transmit the key information over
the secure channel which presumably already has encryption.
> The second one is through the descriptor checksum and visual inspection
of the descriptor itself.
This is a reasonable suggestion, although it's worth noting that support
for storing multisig setups on hardware wallets varies. Coldcard supports
this through importing of a proprietary .txt format file (which has been
adopted by a number of other vendors). Trezor and Ledger (AFAIK) do not
however store multisig setups, which could make this step confusing. With
that said, the use of an output descriptor is certainly a more standardised
approach, albeit one without the wallet name included. By the use of the
singular, I assume you mean a descriptor without the /0/* or /1/* suffix
(which I think is a good idea).
WRT to QR codes, using the BCR UR2.0 standard you linked to is IMO the
right approach. I'll link directly to the two BCR UR2.0 formats here which
are relevant:
1. For sharing the sharing the BIP44 account information from the signers
to the coordinator, the crypto-account format: [
https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-015-account.md
]
2. For sharing the output descriptor from the coordinator to the signers,
the crypto-output format: [
https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-010-output-desc.md
]
Craig
On Tue, Feb 9, 2021 at 9:53 AM Hugo Nguyen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all,
> I would like to propose a new BIP for Secure Multisig Setup.
> This proposal has taken inputs from folks at Coldcard, Shift Crypto and
> Cobo -- listed below as co-authors.
>
> This was inspired by my own experience working with hardware wallets on
> the market, as well as existing research into the challenges of multisig.
>
> Cheers,
> Hugo
>
> <pre>
> BIP: To be determined
> Layer: Applications
> Title: Bitcoin Secure Multisig Setup (BSMS)
> Author: Hugo Nguyen <hugo at nunchuk.io>, Peter Gray <peter at coinkite.com>,
> Marko Bencun <marko at shiftcrypto.ch>, Aaron Chen <aarondongchen at gmail.com>,
> Rodolfo Novak <rodolfo at coinkite.com>
> Comments-Summary: No comments yet.
> Comments-URI:
> Status: Proposed
> Type: Standards Track
> Created: 2020-11-10
> License: BSD-2-Clause
> </pre>
>
> ==Introduction==
>
> ===Abstract===
>
> This document proposes a mechanism to set up multisig wallets securely.
>
> ===Copyright===
>
> This BIP is licensed under the 2-clause BSD license.
>
> ===Motivation===
>
> The Bitcoin multisig experience has been greatly streamlined under [
> https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki BIP-0174
> (Partially Signed Bitcoin Transaction)]. However, what is still missing is
> a standardized process for setting up multisig wallets securely across
> different vendors.
>
> There are a number of concerns when it comes to setting up a multisig
> wallet:
>
> # Whether the multisig configuration, such as Signer membership, script
> type, derivation paths and number of signatures required, is correct and
> not tampered with.
> # Whether Signer persists the multisig configuration in their respective
> storage, and under what format.
> # Whether Signer's storage is tamper-proof.
> # Whether Signer subsequently uses the multisig configuration to generate
> and verify receive and change addresses.
>
> An attacker who can modify the multisig configuration can steal or hold
> funds to ransom by duping the user into sending funds to the wrong address.
>
> This proposal seeks to address concerns #1 and #2: to mitigate the risk of
> tampering during the initial setup phase, and to define an interoperable
> multisig configuration format.
>
> Concerns #3 and #4 should be handled by Signers and is out of scope of
> this proposal.
>
> ==Specification==
>
> ===Prerequisites===
> This proposal assumes the parties in the multisig support [
> https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP32], [
> https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the
> descriptor language] and encryption.
>
> ==Roles==
> ===Coordinator===
>
> The Coordinator initiates the multisig setup. The Coordinator determines
> what type of multisig is used and how many members and signatures are
> needed. If encryption is enabled, the Coordinator generates a secret token,
> to be shared among the parties for secure communication. The Coordinator
> gathers information from the Signers to generate a descriptor record. The
> Coordinator distributes the descriptor record back to the Signers.
>
> ===Signer===
>
> The Signer is a participating member in the multisig. Its responsibilities
> include providing its XPUB to the Coordinator, verifying that its XPUB is
> included in the descriptor record and persisting the descriptor record in
> its storage.
>
> ==Setup Process==
>
> ===Round 1===
>
> ====Coordinator====
>
> * The Coordinator creates a multisig wallet creation session. The
> Coordinator determines the type of multisig script used and the signing
> configuration (<tt>M</tt> and <tt>N</tt>).
> * If encryption is enabled, the Coordinator also generates a secret token,
> hereby denoted <tt>TOKEN</tt>.
> * TOKEN is in ASCII format and must have a minimum of 8 characters. TOKEN
> should expire after some time period determined by the Coordinator, e.g.,
> 24 hours.
> * TOKEN acts as an encryption key among the parties. The method of
> encryption is AES, CTR mode. The encryption key can be calculated by
> performing a double hash operation on the TOKEN: <tt>ENCRYPTION_KEY =
> SHA256(SHA256(TOKEN))</tt>.
> * A TOKEN value of <tt>-1</tt> means that encryption is disabled and all
> the encryption/decryption steps below can be skipped.
> * The Coordinator shares the TOKEN with all participating Signers over a
> secure channel.
>
> ====Signer====
>
> * The Signer generates a key record by prompting the user for the TOKEN
> and a derivation path.
> * The first line in the record must be the <tt>TOKEN</tt>. If encryption
> is disabled, set the TOKEN to -1. The second line must be the <tt>KEY</tt>,
> whereas KEY is an XPUB. KEY must include key origin information and written
> in the descriptor-defined format, i.e.: <tt>[{master key
> fingerprint}/{derivation path}]{XPUB}</tt>. The third line must be a
> <tt>SIG</tt>, whereas SIG is the signature generated by using the
> corresponding private key to sign the first two lines. Finally, the Signer
> encrypts the entire record with ENCRYPTION_KEY.
>
> ===Round 2===
>
> ====Coordinator====
>
> * The Coordinator gathers key records from all participating Signers.
> Abort the setup if TOKEN has expired.
> * For each key record, the Coordinator decrypts it using ENCRYPTION_KEY.
> The Coordinator verifies that the included SIG is valid given the KEY.
> * If all key records look good, the Coordinator generates a descriptor
> record, which is simply the descriptor string plus a <tt>CHECKSUM</tt>, all
> in one line. The CHECKSUM has BECH32 encoding and is described at [
> https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums].
> The Coordinator encrypts this descriptor record with ENCRYPTION_KEY.
> * The Coordinator sends the encrypted descriptor record to all
> participating Signers.
>
> ====Signer====
>
> * The Signer imports the descriptor record, decrypts it by prompting the
> user for TOKEN.
> * The Signer calculates and verifies the descriptor’s CHECKSUM. Abort the
> setup if the CHECKSUM is incorrect.
> * The Signer checks whether one of the KEYs in the descriptor belongs to
> it, using path and fingerprint information included in the descriptor. The
> check must perform an exact match on the KEYs, and not using shortcuts such
> as matching fingerprints (which is trivial to spoof). Abort the setup if it
> doesn’t detect its own KEY.
> * For confirmation, the Signer must display to the user the descriptor's
> CHECKSUM, plus other configurations, such as M and N. The total number of
> Signers, N, is important to prevent a KEY insertion attack. All
> participating Signers should be able to display the same confirmation.
> * If all checks pass, the Signer persists the descriptor record in its
> storage. The Signer should subsequently use the descriptor to generate and
> verify receive and change addresses.
>
> This completes the setup.
>
> ==QR Codes==
> For signers that use QR codes to transmit data, key and descriptor records
> can be converted to QR codes, following [
> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md
> the BCR standard].
>
> ==Security==
>
> This proposal introduce two layers of protection. The first one is a
> temporary, secret token, used to encrypt the two rounds of communication
> between the Signers and the Coordinator. The second one is through the
> descriptor checksum and visual inspection of the descriptor itself.
>
> The token is only needed during the setup phase, and can be safely thrown
> away afterwards. The token does not guarantee that the Signer membership
> set is not modified, since that depends on the overall security of all
> parties in the setup, but it can make it significantly harder for an
> attacker to do so.
>
> There are three ways an attacker can modify the membership set: by
> changing an existing member, by removing an existing member, or by adding a
> new member.
>
> For the first two methods, one of the Signers will be able to detect that
> its membership has been changed or removed, and reject the final
> descriptor. Thus, it is vital that all participating Signers check that
> their membership is intact in the descriptor. Even one Signer failing to
> check for its membership means that the setup could be compromised.
>
> For the third type of attack, the descriptor checksum and visual
> inspection of the descriptor itself are the only way to guard against
> malicious members from being inserted into the set.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210209/52df63dc/attachment-0001.html>