Craig Raw [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2021-01-16 to 2022-09-26
💬 Posted a total of 17 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 23:13:02

- 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-07 23:13:01

- reply

📅 Original date posted:2022-08-24
📝 Original message: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/20220824/025a538b/attachment.html>

2023-06-07 22:56:00

- reply

📅 Original date posted:2021-07-03
📝 Original message:There is a downside to using "h"/"H" from a UX perspective - taking up more
space and appearing as alphanumeric characters similar to the path numbers,
they make derivation paths and descriptors more difficult to read. Also,
although not as important, less efficient when making metal backups.
On Sat, Jul 3, 2021 at 7:13 AM Andrew Chow via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 7/2/21 11:24 PM, David A. Harding wrote:
> > Is there any chance we can take this opportunity to make "h"/"H" the
> > preferred aliases? Using "'" in bourne-style shells is very
> > annoying[1], and I suspect it's also creating unnecessary complications
> > elsewhere.
> I've updated the text to use "h".
> > Alternatives:
> >
> > - Completely kill "'" (I'd prefer this, but I realize it's complicated
> > with descriptors already being used widely). If "h"/"H" are made the
> > preferred aliases, maybe it'd be enough to make implementing "'" a
> > SHOULD rather than a MUST; this would push implementations towards
> > displaying descriptors using the h versions for maximum compatibility.
> Since there already are software implementing descriptors, I don't think
> we can do this. I'm not sure about making "'" a SHOULD either.
> > - Calculate the checksum over s/(h|H)/'/ (again, I know that's
> > complicated with descriptors already widely used)
> This has been discussed in the past and the conclusion was that the
> checksum should be strictly over the string itself. This would allow for
> dumb checksum checkers which don't have to be able to parse descriptors
> in order to check the checksum.
>
> Thanks,
> Andrew
>
> >
> > Thanks,
> >
> > -Dave
> >
> > [1]
> https://github.com/bitcoin/bitcoin/issues/15740#issuecomment-695815432
>
>
> _______________________________________________
> 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/20210703/204d7572/attachment-0001.html>

2023-06-07 22:55:22

- reply

📅 Original date posted:2021-06-23
📝 Original message:+1
While other derivation schemes have been proposed, the simple "purpose per
script type" based approach started with BIP44 is very widely used and has
done much to improve recoverability of wallets. The products and
understanding around this approach are now relatively mature, while backing
up an output descriptor (in addition to seed words) is still not well
understood or supported. Early standardisation around a known derivation
path will ease implementation for wallets implementing Taproot and help
prevent confusion (as we have had over the still draft BIP48). I also agree
we don't need (and should avoid) a new version for extended key
serialization.
Craig
On Wed, Jun 23, 2021 at 3:17 AM Andrew Chow via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi All,
>
> I would like to propose a simple derivation path scheme for keys to be
> used in single key Taproot scripts. This is based on BIP 44 so it is
> basically identical to BIPs 49 and 84. Like with those BIPs, the actual
> value to be used in the purpose level will be set to the BIP number,
> once assigned.
>
> Note that the keys derived in this method should be for the Taproot
> internal key, which should then be tweaked with the hash of itself as
> recommended by BIP 341. The keys derived at this path should not be used
> directly as the Taproot output pubkey. Additionally, this BIP does not
> specify new version bytes for extended key serialization because, with
> the advent of descriptors, I think that is unnecessary. In fact, this
> BIP feels somewhat unnecessary to me, but it seems like it will be
> needed for now in order to drive adoption and implementation of Taproot
> into software and hardware wallets.
>
> The text can be viewed below, with the rendered text available at
>
> https://github.com/achow101/bips/blob/taproot-bip44/bip-taproot-bip44.mediawiki
>
> Andrew Chow
>
> ---
>
> <pre>
> BIP: bip-taproot-bip44
> Layer: Applications
> Title: Derivation scheme for P2TR based accounts
> Author: Andrew Chow <andrew at achow101.com>
> Comments-Summary: No comments yet.
> Comments-URI:
> https://github.com/bitcoin/bips/wiki/Comments:BIP-taproot-bip44
> Status: Draft
> Type: Informational
> Created: 2021-06-22
> License: BSD-2-Clause
> </pre>
>
> ==Abstract==
>
> This document suggests a derivation scheme for HD wallets whose keys are
> involved in single key
> P2TR ([[bip-0341.mediawiki|BIP 341]]) outputs as the Taproot internal key.
>
> ===Copyright===
>
> This BIP is licensed under the 2-clause BSD license.
>
> ==Motivation==
>
> With the usage of single key P2TR transactions, it is useful to have a
> common derivation scheme so
> that HD wallets that only have a backup of the HD seed can be likely to
> recover single key Taproot
> outputs. Although there are now solutions which obviate the need for
> fixed derivation paths for
> specific script types, many software wallets and hardware signers still
> use seed backups which
> lack derivation path and script information. Thus we largely use the
> same approach used in BIPs
> [[bip-0049.mediawiki|49]] and [[bip-0084.mediawiki|84]] for ease of
> implementation.
>
> ==Specifications==
>
> This BIP defines the two needed steps to derive multiple deterministic
> addresses based on a
> [[bip-0032.mediawiki|BIP 32]] master private key.
>
> ===Public key derivation===
>
> To derive a public key from the root account, this BIP uses the same
> account-structure as
> defined in BIPs [[bip-0044.mediawiki|44]], [[bip-0049.mediawiki|49]],
> and [[bip-0084.mediawiki|84]],
> but with a different purpose value for the script type.
>
> <pre>
> m / purpose' / coin_type' / account' / change / address_index
> </pre>
>
> For the <tt>purpose</tt>-path level it uses <tt><BIPNUMBER>'</tt>.
> The rest of the levels are used as defined in BIPs 44, 49, and 84.
>
> ===Address derivation===
>
> To derive the output key used in the P2TR script from the derived public
> key, we use the method
> recommended in
> [[bip-0341.mediawiki#constructing-and-spending-taproot-outputs|BIP 341]]:
>
> <pre>
> internal_key: lift_x(derived_key)
> 32_byte_output_key: internal_key + int(HashTapTweak(bytes(internal_key)))G
> </pre>
>
> In a transaction, the scripts and witnesses are as defined in
> [[bip-0341.mediawiki#specification|BIP 341]]:
>
> <pre>
> witness: <signature>
> scriptSig: (empty)
> scriptPubKey: 1 <32_byte_output_key>
> (0x5120{32_byte_output_key})
> </pre>
>
> ==Backwards Compatibility==
>
> This BIP is not backwards compatible by design.
> An incompatible wallet will not discover these accounts at all and the
> user will notice that
> something is wrong.
>
> However this BIP uses the same method used in BIPs 44, 49, and 84, so it
> should not be difficult
> to implement.
>
> ==Test vectors==
>
> TBD
>
> ==Reference==
>
> * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
> * [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]
> * [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic
> Wallets]]
> * [[bip-0049.mediawiki|BIP49 - Derivation scheme for
> P2WPKH-nested-in-P2SH based accounts]]
> * [[bip-0084.mediawiki|BIP84 - Derivation scheme for P2WPKH based
> accounts]]
> * [[bip-0341.mediawiki|BIP341 - Taproot: SegWit version 1 spending rules]]
>
>
> _______________________________________________
> 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/20210623/5533748e/attachment.html>

2023-06-07 18:30:46

- reply

📅 Original date posted:2021-03-19
📝 Original message:Hi Robert,
I believe many of the same concerns apply in multisig. If one has the
threshold and all the cosigner seeds, the funds in a multisig wallet can
very likely be discovered by checking one of a handful of standard
derivation paths/script types. Is the motivation of this BIP proposal
strong enough to lose this capability?
Craig
On Thu, Mar 18, 2021 at 11:43 PM Robert Spigler <RobertSpigler at protonmail.ch>
wrote:
> (IMO), where this proposal really excels, is mutlisig. And if you check
> my commits, it actually originally was for multisig only, and I extended it
> for multisig and single sig wallets.
>
> ghost43 and Jochen Hoenicke brought up important issues with this proposed
> BIP re: single sig wallets, so I will be reverting this back for multisig
> derivations. I believe that should cover all concerns.
>
> Please view the updated BIP here:
> https://github.com/Rspigler/bips-1/blob/Sane_Mulitisg_deriv/Modern%20Hierarchy%20for%20Deterministic%20Multisignature%20Wallets.mediawiki
>
> And the updated PR here: https://github.com/Rspigler/bips-1/pull/1
>
> Thank you,
>
> Robert
>
> Personal Fingerprint: BF0D 3C08 A439 5AC6 11C1 5395 B70B 4A77 F850 548F
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Thursday, March 18, 2021 4:44 PM, Robert Spigler via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> I (Robert Spigler) will respond in a next post.
>
> Thanks for your comments!
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210319/dab0f192/attachment.html>

2023-06-07 18:29:39

- 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 18:28:39

- 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 18:28:31

- 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>

2023-06-07 18:28:16

- reply

📅 Original date posted:2021-01-16
📝 Original message:Hey Chris,
You can add Sparrow Wallet to the list for Sending :)
I think one of the barriers to greater Payjoin adoption is the need for a
server endpoint on the receiving side. Ideally, all wallets should be able
to conduct Payjoin transactions with each other. This would require a
different mechanism to exchange the PSBTs, but otherwise the specification
should need no amendment. Samourai has implemented their Soroban protocol
to do this over Tor, but as far as I know it's not yet documented.
Given Payjoin is fee efficient (much more so than coinjoin) and relatively
simple to implement, it appears to hold great promise in disrupting
blockchain analysis. I'd love to see a standard that wallets can adopt to
receive Payjoin transactions without a server endpoint.
Craig
On Sat, Jan 16, 2021 at 5:13 AM dev_f via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hey Chris,
>
> I assume that a major reason for the lack of adoption is the lack of
> visibility.
> I personally first found out about PayJoin when using BTCPayServer for a
> donation
> and being told by the site that PayJoin was available (
> https://hrf.org/donate-bitcoin/payjoin/).
> The wiki page you created is a good starting point. Bringing up the issue
> of implementing
> PayJoin directly with the companies / in the respective software repos
> seems like it would
> be a strong first step for greater adoption. Gets more eyes on it in
> general.
> (Directly contributing to the software by writing an implementation is
> obviously the
> most helpful, though clearly harder.)
>
> As a second option, pushing merchants towards accepting Bitcoin
> specifically via
> software like BTCPayServer, which already supports PayJoin, might be
> immensely
> helpful when Bitcoin adoption itself rises.
>
> Fitti
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>
> On Saturday, January 16th, 2021 at 1:07 AM, Chris Belcher via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > PayJoin is an exciting bitcoin privacy technology which has the
> >
>
> > potential to damage the ability of blockchain surveillance to spy on
> >
>
> > bitcoin users and destroy bitcoin's fungibility. A protocol standard has
> >
>
> > already been defined and implemented by a couple of projects such as
> >
>
> > BTCPayServer, Wasabi Wallet, JoinMarket and BlueWallet.
> >
>
> > I've made a wiki page tracking adoption:
> >
>
> > https://en.bitcoin.it/wiki/PayJoin_adoption
> >
>
> > It is similar to the Bech32 adoption page.
> >
>
> > Recently a UK bitcoin exchange shut down due to new regulations, with
> >
>
> > the owner writing a very interesting and relevant blog post that I'll
> >
>
> > quote here:
> >
>
> > > you’re considered suspicious if you used a marketplace and not an
> >
>
> > exchange. Coinjoin counts as high risk. Gambling is high risk. As you
> >
>
> > use entities that are paranoid about keeping their coins clean and
> >
>
> > adhering to all the regulations, your risk scores will continue to
> >
>
> > increase and without you even knowing why, your deposits will become
> >
>
> > rejected, you may be asked to supply documents or lose the coins, your
> >
>
> > account may become suspended without you having any clue what you did
> >
>
> > wrong. And quite possibly you didn’t do anything wrong. But that won’t
> >
>
> > matter.
> >
>
> > > The goal post, the risk score threshold will keep moving along this
> >
>
> > trend until the point where you will be afraid of using your personal
> >
>
> > wallet, donating to someone online, receiving bitcoins from anywhere
> >
>
> > except for regulated exchanges. At that point, crypto will be akin to a
> >
>
> > regular bank account. You won’t have a bitcoin wallet, you will have
> >
>
> > accounts to websites.
> >
>
> > https://blog.bitbargain.com/post/638504004285054976/goodbye
> >
>
> > If we want bitcoin to fulfill its dream of a permissionless money for
> >
>
> > the internet then we'll have to work on this. What can we do to increase
> >
>
> > adoption of PayJoin?
> >
>
> > 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/20210116/005e8719/attachment.html>