Clark Moody [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-07-14 to 2022-08-25
💬 Posted a total of 13 messages
📚 Participated in the following categories: bitcoin-dev, BIP proposal
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 23:13:07

- reply

📅 Original date posted:2022-08-25
📝 Original message:Having previously developed an export format[1] for general cryptocurrency transaction information, I can attest to the value of the human-readable CSV. I was careful to mention the RFC 4180 spec so that implementations could avoid the pitfalls of incorrect CSV encoding.
[1]: https://github.com/harmony-csv/harmony
Clark
------- Original Message -------
On Thursday, August 25th, 2022 at 3:59 AM, Craig Raw via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Thanks for your thoughts Ryan.
>
> Without reference to the quality feedback on this proposal, I was aware when submitting it for review that it provides an excellent opportunity for bike shedding. As developers, we have all experienced frustration with data formats. One thing that I did not perhaps make clear enough is that this format is not solely intended for developers, but general users who are probably not well represented on this list.
>
> While doing research for this proposal I spoke to several professional users of Sparrow Wallet (who are not developers). They all expressed a desire for the format to integrate with their business processes, which are driven by business tools such as Excel. Labelling provides an important function in UTXO and address management in these scenarios, and needs to be accessible and manageable outside of wallet software.
>
> If this is to be achieved, it immediately rules out JSON as a data format. Not only is JSON limited to editing only through specific software or text editors, but (in the latter case) it is fragile enough that a single missing character can cause an entire file to fail parsing. CSV is more forgiving in this regard. With respect to your comments on escaping, my expectation would be that developers will be using a mature CSV library rather than handling character escaping themselves. I would rather propose a format that is generally usable, even if occasionally a label is escaped incorrectly.
>
> Finally, I'll note that CSV files are already common and uncontroversial in Bitcoin wallet software. Bitcoin Core, Electrum, Sparrow (and no doubt many others) already export addresses and/or transactions with their labels as CSV files. This proposal simply attempts to create a standard for importing and exporting all the labels in a wallet.
>
> Craig
>
> On Wed, Aug 24, 2022 at 9:01 PM <rhavar at protonmail.com> wrote:
>
>> I'd strongly suggest not using CSV. Especially for a standard. I've worked with it as an interchange format many a times, and it's always been a clusterfuck.
>>
>> Right off the bat, you have stuff like "The fields may be quoted, but this is unnecessary as the first comma in the line will always be the delimiter" which invariably leads to some implementations doing it, some implementations not doing it, and others that are intolerant of the other way.
>>
>> And you have also made the classic mistake of not strictly defining escape rules. So everyone will pick their own (e.g. some will \, escape commas, others will not cause it's quoted and escape quotes, and others will assume no escaping is required since its the last column in a csv).
>>
>> Over time it morphs into its own mini-monster that introduces so much pain.
>>
>> On a similar note, allowing alternatives (like: txid>index vs txid:index) provides no benefit, but creates additional work for implementations (who quite likely only test formats they produce) and future incompatibilities.
>>
>> I know everyone loves to hate on it, but really (line-separated?) json is the way to go.
>>
>> { "tx": "c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎", "label": "wow, such label" }
>> { "tx: "c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b", "txout": 4, "label": "omg this is so easy to parse" }
>> { "tx: "c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b", "txin": 0, "label": "wow this is going to be extensible as well" }
>>
>> -Ryan
>>
>> ------- Original Message -------
>> On Wednesday, August 24th, 2022 at 2: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/20dfb197/attachment-0001.html>

2023-06-07 23:13:01

- reply

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

2023-06-07 23:10:49

- reply

📅 Original date posted:2022-06-29
📝 Original message:Alfred,
Thanks for the proposal. This is really interesting, especially the
additional on-chain privacy improvements over BIP47: ephemeral
notifier/sender keys and shielding of the sender key(s) against
seizure of the recipient's wallet.
> A payment code is encoded in base58check and the version byte produces "S" for the first character.
This is a bit under-specified, but let me bike-shed here and suggest
going with a Bech32m encoding. We gain more compact QR codes as well
as error detection/correction.
Alternate proposal:
- Bech32m human-readable part = "pay"
- Data payload is [watched address type bytes (2), compressed pubkey (33)]
Example:
- Address type bytes = c000
- Pubkey 03b54543fbed9d17d9300b508c55769bc4c8385620626730b4d52e5f3e30d9a6c1
- Published payment code:
pay1cqqq8d29g0a7m8ghmycqk5yv24mfh3xg8ptzqcn8xz6d2tjl8ccdnfkpjl7p84
> The owner of a code could simply demand that a notification transaction meets some minimum miner fee or a multiple of some trailing average.
I don't see how this would work, and others have pointed out that the
cost of block space is itself an anti-spam measure.
== Notification Service Idea ==
A third-party service could offer to publish OP_RETURN notification
payloads in the blockchain for a fee, paid over Lightning Network.
This completely de-links Alice's notification from her wallet, while
accepting the less-known privacy implications of a Lightning payment.
The service would remain ignorant of Bob's identity in any event. Such
a service would also be incentivized to charge market rates for the
potential privacy boost and for block space.
== Data Service Idea ==
Another service could publish only the OP_RETURN data pertaining to
this BIP, which is easy to obtain due to the clear tagging scheme.
Light wallets would check in with this service on a regular basis,
performing the ECDH filtering steps on each output. Upon further
request, the service furnishes transaction proofs for the full
transaction containing the OP_RETURN. Care would need to be taken to
avoid leaking too much information to the service, and techniques such
as using separate Tor circuits or requesting tx proofs on a bulk set
of transactions could help obfuscate the exact transaction of
interest. These concerns are similar to those found in BIP157
client-side block filtering (Neutrino filters).
Alternatively, the service publishes the block height along with the
notification data contained within that block. Light clients could
download relevant blocks over the p2p network and perform full
validation.
-Clark
On Mon, Jun 27, 2022 at 2:14 PM Alfred Hodler via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi,
>
> There have been attempts to create static payment codes that function as a way for transacting parties to create "private" addresses, where private stands for "known only to transacting parties". BIP47 was one such standard.
>
> The standard suffered from a number of problems:
>
> 1. The standard promised extensibility through versioning but it never used that capability to follow innovations in the Bitcoin protocol. It was designed around the idea that legacy p2pkh addresses would always be the primary and only way to transact. As new standard script types started to emerge (Segwit v0, Taproot), the creators dealt with the problem by stating that implementing wallets should scan for all existing standard scripts. The inability of payment codes to explicitly state which address types they derive places a burden on more resource constrained wallets.
>
> 2. The standard relied on a notification mechanism in order to connect a sender with a recipient, which included either offchain technology (Bitmessage), or so called "notification addresses" which a) left a footprint b) created toxic change. That type of footprint is particularly harmful because it makes it obvious that a particular recipient is going to receive private transactions. If the notifying party performs this process with coins linked to its identity (i.e. tainted or non-anonymized inputs), it forever becomes visible that Alice connected with Bob despite the fact that her payment code was blinded. While future transactions and their amounts aren't visible, this metadata makes it possible to build a social graph.
>
> 3. The standard was implemented only by an entity that disavowed the BIP process and didn't wish to use it to keep the standard up to date. Further updates did take place but only outside the BIP process, creating a lack of clarity as to what the real specification is. Ultimately the standard was abandoned.
>
> I propose to build on the idea of payment codes under a new BIP with the following principal differences:
>
> 1. The new standard will allocate a 2-byte bitflag array that will signal address/script types that the receiver is deriving. Since the vast majority of scripts are p2pkh (47.3%) and p2wpkh (26.2%), bits 0 and 1 will be used for those respectively. Bit 2 will be p2tr. The remaining 13 bits are reserved for future standard script types.
>
> 2. Notification transactions still exist but no longer leave a privacy footprint on the blockchain. Instead, a notification transaction is simply a single OP_RETURN containing a value that only Alice and Bob can calculate. If Alice's notification transaction uses UTXOs not associated with her identity, there is never a footprint showing that either her or Bob are using private payments. If Alice uses tainted coins, only she is exposed as a user of Private Payments but Bob still isn't.
>
> 3. Payment code versioning is no longer done because it creates the potential for fragmentation and disparate standard updates by different parties that don't follow the BIP process (BIP47 is a good example of that).
>
> 4. Relying on static compressed pubkeys as opposed to extended keys means shorter payment codes.
>
> ==Proposed Payment Code Structure==
>
> bytes 0-1: - enabled (watched) address types (16 possible address types)
> bytes 2-35: - compressed public key P
>
> ==Encoding==
>
> A payment code is encoded in base58check and the version byte produces "S" for the first character. A code might look like "SwLUHs3UfMUXq956aXLTUPPfow7a8gDfSUUAtafwqHcobf6mKcMbJk".
>
> ==Pubkey Derivation==
>
> Recipient's payment code pubkey `P` is derived from a master key using the following path: `m/purpose'/coin_type'/account'`. `purpose` will be defined once a BIP number is assigned. Its corresponding private key is `p`.
>
> Notifier/sender's pubkey `N` is derived using the following derivation path: `m/purpose'/coin_type'/account'/*`, where each recipient gets a new index. This way send-side privacy is always preserved. Its corresponding private key is `n`.
>
> ==Notifications==
>
> Alice wants to notify Bob that he will receive future payments from her. Alice selects any UTXO in her wallet (preferably not associated with her) and `n_Alice`. Alice selects the public key contained in Bob's payment code `P_Bob`. Alice performs the following process (`*` and `+` are EC operations):
>
> notification = SHA256(n_Alice * P_Bob)
>
> Alice then constructs a 72-byte OP_RETURN output whose value is set to `BIPXXXX + notification + N_Alice` (`+` is concat) and sends it in a transaction containing no other outputs (XXXX to be replaced once a BIP number is assigned). Alice MUST now keep track of `n_Alice` or its derivation path as it will be used in future transactions exclusively with Bob (not for spending but to calculate secret addresses).
>
> Bob's wallet receives whole blocks but doesn't need to waste resources on decoding them if the environment is resource constrained. Bob simply needs find the string BIPXXXX in the binary blob that represents an undecoded block. Once found, Bob extracts the subsequent 32 bytes (`notification`) and the subsequent 33 bytes (`N_Alice`). The benefit of this approach is that Bob doesn't have to decode blocks and extract pubkeys from scriptsigs.
>
> Since ECDH dictates that SHA256(n_Alice * P_Bob) == SHA256(N_Alice * p_Bob), Bob calculates the expected notification value and checks if it matches the first value in the payload. If so, Bob found a notification transaction addressed to himself and stores `N_Alice` in order to be able to detect and spend future payments from Alice. The added benefit of this approach over BIP47 is that Bob doesn't learn Alice's payment code, so Alice can pay Bob without revealing her identity. To take advantage of these privacy benefits, Alice simply has to engage in coin control on her end. A real world scenario where this might be useful is anonymous donations to a party whose wallet may be seized in the future. Seizing such a wallet won't reveal who Alice is (as long as she engages in coin control), whereas BIP47 would by default leak her identity even if her coins as anonymized.
>
> If this process fails for any reason, Bob assumes a spurious notification or one not addressed to himself and gives up.
>
> ==Transacting==
>
> Now that they are connected, Alice can send transactions to Bob. Alice needs to keep track of her transaction count toward Bob; let's name that counter `X`. This process is similar to what BIP47 does.
>
> Alice calculates a secret point:
>
> S = n_Alice * P_Bob
>
> Alice calculates a shared secret:
>
> s = SHA256(S, X)
>
> Alice calculates Bob's ephemeral public key and its associated address where the funds will be sent:
>
> P_Bob' = P_Bob + s*G
>
> When Bob detects a payment to `P_Bob'`, he can spend such coins by calculating the shared secret `s` in the same manner using `N_Alice` and `p_Bob` and performing:
>
> p_bob' = p_bob + s
>
> The fact that Alice and Bob are using a shared counter means we can do away with chain codes and make payment codes much smaller. Bob simply needs to derive a number of addresses to watch with respect to some gap limit (which can be as low as 1 in practice).
>
> ==Anti-spam==
>
> While DoS hasn't been a problem with BIP47, it is possible to build anti-spam measures into payment codes. The owner of a code could simply demand that a notification transaction meets some minimum miner fee or a multiple of some trailing average. This would help prevent spam notifications that might otherwise overwhelm a payment code with addresses to watch. But that is purely optional.
>
> Looking forward to hearing thoughts and ideas.
>
> Alfred
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 22:51:44

- reply

📅 Original date posted:2021-04-16
📝 Original message:Maybe I missed something, but why does this change require a hard fork?
You don't seem to provide any data as part of your rationale, so I'll
provide some context. As it stands, the chain size sits around 386 GB, with
OP_RETURN data accounting for 2.5 GB of that.
I'm also concerned about the coordination required to get into The One
OP_RETURN Per Block, as this certainly requires some measure of
centralization of that Merkle Tree construction.
Some of those OP_RETURN outputs have non-zero value. As such, those outputs
are provably unspendable, and they are essentially paying the rest of the
coin holders via supply deflation.
Finally, Bitcoin nodes may safely discard OP_RETURN outputs at any time,
since they are unspendable. Thus, nodes can clear a few GB of disk space
whenever they need it, but that data is less than 1% of the total chain
size at the time of writing.
-Clark
On Fri, Apr 16, 2021 at 8:32 AM Christopher Gilliard via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I have created a BIP which can be found here:
> https://github.com/cgilliard/bips/blob/notarization/bip-XXXX.mediawiki
>
> I'm sending this email to start the discussion regarding this proposal. If
> there are any comments/suggestions, please let me know.
>
> Regards,
> Chris
> _______________________________________________
> 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/20210416/7954d8e1/attachment.html>

2023-06-07 18:27:36

- reply

📅 Original date posted:2020-11-25
📝 Original message:Thanks for this! I can't comment on the correctness of your implementation,
but I really appreciate the idea and effort.
By chance, did you come across any other spec definitions in alternate
formal grammars?
-Clark
On Wed, Nov 25, 2020 at 5:35 AM Dmitry Petukhov via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I have created a formal specification of Miniscript [1] using
> the specification language of Alloy analyzer [2]
>
> Link: https://github.com/dgpv/miniscript-alloy-spec
>
> Possible uses for the spec:
>
> - Implementing Miniscript libraries, as additional reference that might
> be easier to navigate than prose spec
>
> - Generating test cases for implementations, although currently this
> will be a manual process due to the tools limitation (can be overcome
> with GUI automation)
>
> - Checking the implementation against the spec, by writing a program
> that would generate Alloy .als files from the data structures of the
> implementation, and then checking these files in Alloy
>
> - Extending or amending Miniscript, if the need arise. Having
> extenstions and changes checked (with bounds) against a spec should
> help catch inconsistencies
>
> - Exploring the properties of Miniscript
>
> If you have an interest in Miniscript, please consider looking at the
> spec and share your ideas.
>
> The spec may contain mistakes, as it was not yet checked against any
> implementation, it was only checked for consistency using its own
> predicates, with the scope of up to 8 nodes.
>
> If you notice a mistake or inconsistency, please submit an issue on
> github (or communicate this in other ways)
>
> [1] http://bitcoin.sipa.be/miniscript/
> [2] https://alloytools.org/
> _______________________________________________
> 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/20201125/b23d248c/attachment.html>

2023-06-07 18:21:37

- reply

📅 Original date posted:2019-11-13
📝 Original message:I agree on all points. The address space already brings enough confusion to
users out there. As it stands, we can use script version and program length
for address validity. Sneaking an alternate checksum into the mix for
different length programs lets us lean on our parsing libraries and not
increase cognitive load for users.
-Clark
On Sun, Nov 10, 2019 at 7:02 PM Matt Corallo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Seems good to me, though I'm curious if we have any (even vaguely)
> immediate need for non-32/20-byte Segwit outputs? It seems to me this
> can be resolved by just limiting the size of bech32 outputs and calling
> it a day - adding yet another address format has very significant
> ecosystem costs, and if we don't anticipate needing it for 5 years (if
> at all)...lets not jump to pay that cost.
>
> Matt
>
> On 11/10/19 9:51 PM, Pieter Wuille via bitcoin-dev wrote:
> > On Thu, Nov 7, 2019, 18:16 David A. Harding <dave at dtrt.org
> > <mailto:dave at dtrt.org>> wrote:
> >
> > On Thu, Nov 07, 2019 at 02:35:42PM -0800, Pieter Wuille via
> > bitcoin-dev wrote:
> > > In the current draft, witness v1 outputs of length other
> > > than 32 remain unencumbered, which means that for now such an
> > > insertion or erasure would result in an output that can be spent by
> > > anyone. If that is considered unacceptable, it could be prevented
> by
> > > for example outlawing v1 witness outputs of length 31 and 33.
> >
> > Either a consensus rule or a standardness rule[1] would require
> anyone
> > using a bech32 library supporting v1+ segwit to upgrade their
> library.
> > Otherwise, users of old libraries will still attempt to pay v1
> witness
> > outputs of length 31 or 33, causing their transactions to get
> rejected
> > by newer nodes or get stuck on older nodes. This is basically the
> > problem #15846[2] was meant to prevent.
> >
> > If we're going to need everyone to upgrade their bech32 libraries
> > anyway, I think it's probably best that the problem is fixed in the
> > bech32 algorithm rather than at the consensus/standardness layer.
> >
> >
> > Admittedly, this affecting development of consensus or standardness
> > rules would feel unnatural. In addition, it also has the potential
> > downside of breaking batched transactions in some settings (ask an
> > exchange for a withdrawal to a invalid/nonstandard version, which they
> > batch with other outputs that then get stuck because the transaction
> > does not go through).
> >
> > So, Ideally this is indeed solved entirely on the bech32/address
> > encoding side of things. I did not initially expect the discussion here
> > to go in that direction, as that could come with all problems that
> > rolling out a new address scheme in the first place has. However, there
> > may be a way to mostly avoid those problems for the time being, while
> > also not having any impact on consensus or standardness rules.
> >
> > I believe that most new witness programs we'd want to introduce anyway
> > will be 32 bytes in the future, if the option exists. It's enough for a
> > 256-bit hash (which has up to 128-bit collision security, and more than
> > 128 bits is hard to achieve in Bitcoin anyway), or for X coordinates
> > directly. Either of those, plus a small version number to indicate the
> > commitment structure should be enough to encode any spendability
> > condition we'd want with any achievable security level.
> >
> > With that observation, I propose the following. We amend BIP173 to be
> > restricted to witness programs of length 20 or 32 (but still support
> > versions other than 0). This seems like it may be sufficient for several
> > years, until version numbers run out. I believe that some wallet
> > implementations already restrict sending to known versions only, which
> > means effectively no change for them in addition to normal deployment.
> >
> > In the mean time we develop a variant of bech32 with better
> > insertion/erasure detecting properties, which will be used for witness
> > programs of length different from 20 or 32. If we make sure that there
> > are never two distinct valid checksum algorithms for the same output, I
> > don't believe there is any need for a new address scheme or a different
> > HRP. The latter is something I'd strongly try to avoid anyway, as it
> > would mean additional cognitive load on users because of another
> > visually distinct address style, plus more logistical overhead
> > (coordination and keeping track of 2 HRPs per chain).
> >
> > I believe improving bech32 itself is preferable over changing the way
> > segwit addresses use bech32, as that can be done without making
> > addresses even longer. Furthermore, the root of the issue is in bech32,
> > and it is simplest to fix things there. The easiest solution is to
> > simply change the constant 1 that is xor'ed into the checksum before
> > encoding it to a 30-bit number. This has the advantage that a single
> > checksum is never valid for both algoritgms simultaneously. Another
> > approach is to implicitly including the length into the checksummed data.
> >
> > What do people think?
> >
> > Cheers,
> >
> > --
> > Pieter
> >
> >
> > _______________________________________________
> > 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/20191112/a92d5501/attachment-0001.html>

2023-06-07 18:15:00

- reply

📅 Original date posted:2018-10-18
📝 Original message:I agree with spelling out the `address` field.
As for "value is either an address or an array of addresses", there is no
standard for specifying an array in a URI, and processing different
querystring schemes is application-specific. (see
https://stackoverflow.com/a/9547490)
Since those app-specific methods don't necessarily preserve order, which is
important here, the most compatible fallback is a delimiter-separated list
under one parameter. Most languages have library functions for splitting
strings on commas.
-Clark
On Thu, Oct 18, 2018 at 5:13 PM vv01f via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I already pointed out a while ago that the separator could be the & and
> the returning value is either an address or an array of addresses.
> So no comma or other delimiter needed.
> also I would suggest to call the parameter `address` and not a shortcut
> for it as we are used to `message` and `amount` spelled out as well.
>
> On 18.10.2018 16:20, Clark Moody via bitcoin-dev wrote:
> > Since we don't know what sort of address changes will happen later on,
> you
> > could make this future-proof by passing a list of addresses to `addr`.
> >
> > The syntax is
> >
> > bitcoin:<address>[?addr=<address>[,<address>[,<address>]]]
>
> _______________________________________________
> 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/20181018/829726f5/attachment.html>

2023-06-07 18:14:59

- reply

📅 Original date posted:2018-10-18
📝 Original message:Since we don't know what sort of address changes will happen later on, you
could make this future-proof by passing a list of addresses to `addr`.
The syntax is
bitcoin:<address>[?addr=<address>[,<address>[,<address>]]]
The addresses passed as a comma-separated list to the `addr` parameter are
in descending order of preference, with highest first. A consumer of this
URI should attempt to understand each address in the list before falling
back to the next address and finally to the base address after `bitcoin:`.
Example:
bitcoin:3xBase58compatibleAddress?addr=fancyFutureEncoding0x01,bech32address1qx01
The spending wallet would attempt to spend to "fancyFutureEncoding0x01"
then to "bech32address1qx01" and finally to "3xBase58compatibleAddress".
Thanks,
-Clark
On Sun, Oct 14, 2018 at 3:14 PM Srintuar via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> An extremely simple BIP write-up for a backward compatible URI scheme to
> help with segwit adoption by online stores and merchants.
>
>
>
> ====
>
> This BIP is a modification of an earlier [[bip-0021.mediawiki|BIP 0021]]
> by Nils Schneider and Matt Corallo
>
> ==Abstract==
> This BIP proposes a URI scheme which allows for backward compatibility
> with native segwit (bech32) wallets and legcy wallets (base58)
>
> ==Motivation==
> The purpose of this URI scheme is to enable all users to easily make
> payments from any wallet, without allowing backward compatibility to be a
> barrier to segwit adoption. This BIP allows a merchant to preferentially
> receive payments to a bech32 address, while gracefully allowing older
> clients to make base58 encoded payments.
>
> ==Specification==
>
> === Query Keys ===
>
> *addr: an alternative bitcoin destination which is preferred over the
> "bitcoinaddress" field of the url
>
> == Appendix ==
>
> === Simpler syntax ===
>
>
> <nowiki>bitcoin:<address>[?amount=<amount>][?label=<label>][?message=<message>][?addr=<bech32address>]</nowiki>
>
> === Examples ===
>
> Just the address:
>
> bitcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?addr=bc1q5u92yq20hss4rc99mfu23h4dxkxn4uuyqd5dzy&amount=50&label=Luke-Jr&message=Donation%20for%20project%20xyz
>
>
> == Reference Implementations ==
> === Bitcoin clients ===
>
> * none yet
>
> _______________________________________________
> 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/20181018/94b3ba54/attachment.html>

2023-06-07 18:14:44

- reply

📅 Original date posted:2018-09-12
📝 Original message:This is the sort of thing I expect to emerge from the places that use
Bitcoin "on the street." We should be watching how local wallet software
displays bitcoin amounts, letting the standards write themselves over time.
The units debate (bits, millibits, etc) has been going on nearly as long as
I've known about Bitcoin and yet most tools display standard bitcoin
amounts (1 unit = 1e8 satoshi).
-Clark
On Wed, Sep 12, 2018 at 8:41 AM Martin Damgaard via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> A very good point. I have realized the immature nature of my suggestion
> due to this and a number of other good remarks, and will like to retract
> the initial suggestion.
>
> Thank you and all the best
>
> Martin Damgaard
>
>
>
> *Fra: *Karl-Johan Alm <karljohan-alm at garage.co.jp>
> *Sendt: *12. september 2018 08:14
> *Til: *damgaard.martin at gmail.com; Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>
> *Emne: *Re: [bitcoin-dev] Suggestion for a universal bitcoin value scale
>
>
>
> A potential problem is that it would be a new attack vector to simply
>
> color something to appear as e.g. 10x more than it really is, if
>
> everyone started using this system.
>
> On Sun, Aug 19, 2018 at 5:27 AM Martin Damgaard via bitcoin-dev
>
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> >
>
> > Hi bitcoin-dev at lists.linuxfoundation.org
>
> >
>
> > Here is my humble attempt to make a contribution to the impressive work
> that you all are doing.
>
> >
>
> > I am unfamiliar with the normal BIP procedures. I have therefore just
> tried to follow the example of BIP 176 by Jimmy Song, in order make
> something similar. I suggest a universal bitcoin value color scale, for
> tackling the same decimal problem, as identified by the BIP 176 proposal.
>
> >
>
> > I have attached the document in three different formats (*.rtf, *.pdf
> and *.docx) as I do not know your preferred format. I hope you will find my
> suggestion useful.
>
> >
>
> >
>
> >
>
> > Thank you and all the best
>
> >
>
> > Martin Damgaard
>
> >
>
> > _______________________________________________
>
> > 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/20180912/c2479290/attachment-0001.html>

2023-06-07 18:11:52

- reply

📅 Original date posted:2018-05-03
📝 Original message:Paul,
The current BIP-49 / 84 use the purpose field of the derivation path to specify
the address format.
I think sticking with the one-BIP-one-format method works. Otherwise, you
would need to modify this proposed BIP each time a new format comes along.
In that case, existing wallets that claim BIP-XXXX compliance will be
incomplete.
-Clark
On Thu, Apr 26, 2018 at 9:05 AM, Paul Brown <paul at 345.systems> wrote:
> Hi
>
> I realised after I sent my previous response that the encoding was wrong
> and that my smiley face at the end of the BIP number comment got turned
> into a ? and the tongue in cheek context was lost :-(
>
> Anyway, back onto subject. I've been thinking some more on the SLIP-0032
> adoption in this proposal and specifically the address format to use when
> generating addresses.
>
> My proposal states bech32 serialized addresses (P2WPKH or P2WSH), however,
> I wonder whether there is some merit in extending the derivation path with
> an additional level below coin type to represent the address format, with
> the value determined by the context of the coin type value in the
> derivation path (0x00 for P2WPKH bech32, 0x01 for P2PKH base58 if coin type
> is Bitcoin, 0x00 for Ethereum account format if coin type is Ether, etc).
> A separate spec similar to SLIP-0044 could be created that defines the list
> of address formats and the derivation path values.
>
> When importing root master seeds or distributing the xpub's for each
> cosigner to each party the discovery process in the proposal would need
> extending to try each address format in turn to determine whether there is
> a 'hit' when checking balances. It does mean that the import process is
> slower however the additional flexibility of supporting multiple address
> formats possibly outweighs this. I'm just thinking that having a rule to
> follow during discovery, particularly where non-Bitcoin coins are
> concerned, is more explicit than leaving it open to the wallet implementer
> to figure out (for altcoins, what address format to use?).
>
> It also means that future address formats are supported as they are simply
> added to the new spec list for the coin type (can be done by anyone,
> similar to the way SLIP-0044 works now) - it doesn't require a new BIP to
> support. For example, if address format was a derivation level in BIP44,
> would BIP49 and BIP84 be needed?
>
> I'm somewhat musing out loud here, but I like the idea of being able to
> mostly self-discover as much as possible and reducing or eliminating the
> need for proprietary metadata attached to the wallet.
>
> Cheers
> Paul
>
> From: clarkmoody at gmail.com <clarkmoody at gmail.com> On Behalf Of Clark Moody
> Sent: 25 April 2018 15:36
> To: Paul Brown <paul at 345.systems>; Bitcoin Protocol Discussion <
> bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Multi-signature and multi-coin HD wallet in one
> BIP32 derivation path (new BIP)
>
> Thanks for the proposal, Paul.
>
> > - What address format is expected when discovering balances and creating
> transactions?
>
> Your solution does not solve your first bullet point, since the xpub
> encoding looks no different than any other xpub (BIP 44, 45, 49, etc). At
> the least, you should propose new version bytes to change the "xpub" in the
> encoding to some other string.
>
> Alternatively, I would suggest that you use the xpub serialization format
> described in SLIP-0032 (
> https://github.com/satoshilabs/slips/blob/master/slip-0032.md). It
> includes the derivation path within the xpub itself and uses Bech32 for
> encoding.
>
> Given a normal xpub with no additional information, a wallet must scan the
> address space for the various formats. SLIP-0032 solves this bootstrapping
> problem and avoids the UX nightmare of users being required to know to
> which BIP number the xpub conforms.
>
> Also, @luke-jr will give you a hard time to self-assigning a BIP number ;-)
>
> Thanks
>
>
>
>
> -Clark
>
> On Wed, Apr 25, 2018 at 4:35 AM, Paul Brown via bitcoin-dev <mailto:
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi
>
> I have written a new BIP describing a BIP32 derivation path that supports
> a single or multi-signature and multi-coin wallet from a single master
> seed. It combines BIP44 and BIP45 and adds in a self-describing structure
> in the derivation path for multiple multi-sig combinations within the
> single wallet along with an extended public key export file format for
> public key distribution between parties. I can particularly see this being
> useful for multiple Lightning Network 2of2 accounts for different payment
> channels.
>
> The BIP can be found here:
> https://github.com/gluexchange/bip/blob/master/bip-0046.mediawiki
>
> I appreciate that this might be re-hashing old ground as BIP44 in
> particular has been widely adopted, however, BIP44 does leave itself open
> to a lot of interpretation from a wallet portability perspective such as:
>
> - What address format is expected when discovering balances and creating
> transactions?
> - Does the master seed represent a single-sig or multi-sig wallet?
> - If multi-sig, how many cosigners and what are their extended public keys
> (so that the wallet can generate the correctly formatted redeem script with
> public keys in the right order)?
> - If multi-sig, how do you prevent collisions on the same address index
> (in a wallet that is occasionally connected)?
>
> BIP45 solves the collision that occurs when the individual parties in a
> multi-sig group each give out a new address from a wallet, where the wallet
> hasn’t been able to sync to mark the address as ‘used’ (this could happen
> if they gave out addresses independently at the same time). It uses a
> cosigner index in the derivation path so that each party has their own path
> to their addresses. However, BIP45 drops the multi-coin support that BIP44
> has.
>
> This is a useful discussion on the problems of a collision and the merits
> of separating cosigners in the derivation path:
> https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg05188.html
>
> For the purposes of the BIP text (and the example paths used to generate
> keys) I’ve temporarily assigned it the number 46. It looks like that is
> available and seemed somewhat appropriate given that it builds on the good
> work of BIP44 and BIP45.
>
> Paul Brown
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> mailto: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/20180504/90c4be2c/attachment-0001.html>

2023-06-07 18:11:41

- reply

📅 Original date posted:2018-04-25
📝 Original message:Thanks for the proposal, Paul.
*> - What address format is expected when discovering balances and creating
transactions?*
Your solution does not solve your first bullet point, since the xpub
encoding looks no different than any other xpub (BIP 44, 45, 49, etc). At
the least, you should propose new version bytes to change the "xpub" in the
encoding to some other string.
Alternatively, I would suggest that you use the xpub serialization format
described in SLIP-0032 (
https://github.com/satoshilabs/slips/blob/master/slip-0032.md). It includes
the derivation path within the xpub itself and uses Bech32 for encoding.
Given a normal xpub with no additional information, a wallet must scan the
address space for the various formats. SLIP-0032 solves this bootstrapping
problem and avoids the UX nightmare of users being required to know to
which BIP number the xpub conforms.
Also, @luke-jr will give you a hard time to self-assigning a BIP number ;-)
Thanks
-Clark
On Wed, Apr 25, 2018 at 4:35 AM, Paul Brown via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi
>
>
>
> I have written a new BIP describing a BIP32 derivation path that supports
> a single or multi-signature and multi-coin wallet from a single master
> seed. It combines BIP44 and BIP45 and adds in a self-describing structure
> in the derivation path for multiple multi-sig combinations within the
> single wallet along with an extended public key export file format for
> public key distribution between parties. I can particularly see this being
> useful for multiple Lightning Network 2of2 accounts for different payment
> channels.
>
>
>
> The BIP can be found here: https://github.com/gluexchange/bip/blob/master/
> bip-0046.mediawiki
>
>
>
> I appreciate that this might be re-hashing old ground as BIP44 in
> particular has been widely adopted, however, BIP44 does leave itself open
> to a lot of interpretation from a wallet portability perspective such as:
>
>
>
> - What address format is expected when discovering balances and creating
> transactions?
>
> - Does the master seed represent a single-sig or multi-sig wallet?
>
> - If multi-sig, how many cosigners and what are their extended public keys
> (so that the wallet can generate the correctly formatted redeem script with
> public keys in the right order)?
>
> - If multi-sig, how do you prevent collisions on the same address index
> (in a wallet that is occasionally connected)?
>
>
>
> BIP45 solves the collision that occurs when the individual parties in a
> multi-sig group each give out a new address from a wallet, where the wallet
> hasn’t been able to sync to mark the address as ‘used’ (this could happen
> if they gave out addresses independently at the same time). It uses a
> cosigner index in the derivation path so that each party has their own path
> to their addresses. However, BIP45 drops the multi-coin support that BIP44
> has.
>
>
>
> This is a useful discussion on the problems of a collision and the merits
> of separating cosigners in the derivation path:
> https://www.mail-archive.com/bitcoin-development@lists.
> sourceforge.net/msg05188.html
>
>
>
> For the purposes of the BIP text (and the example paths used to generate
> keys) I’ve temporarily assigned it the number 46. It looks like that is
> available and seemed somewhat appropriate given that it builds on the good
> work of BIP44 and BIP45.
>
>
>
> Paul Brown
>
>
>
>
>
> _______________________________________________
> 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/20180425/14fbc624/attachment-0001.html>

2023-06-07 18:08:43

- reply

📅 Original date posted:2017-12-14
📝 Original message:An alternative to "training" users to understand SI prefixes could be to
make 100 satoshi = 1 mu, spelling out the Greek letter.
Although the Units <https://en.bitcoin.it/wiki/Units> page on the wiki has
been brought up to argue against naming 10,000 satoshi = 1 finney, I would
like to support this designation. It seems to be gaining some popular
support on Twitter & podcasts. So at $10,000 BTC/USD, 1 finney = $1.00. The
smallest unit of value would be 0.0001 finney = 1 satoshi. Finney has a
natural abbreviation as fin, and 100 mu = 1 finney.
The Units page also refers to "bitcent" as 0.01 BTC, but if a "bit" is 100
satoshi, then what is a "bitcent" in that context?
/bikeshed
@Natanael you're exactly right. There are already multiple uses of "bits"
within bitcoin itself.
@Sjors I don't think a redefinition of 'satoshi' is going to happen ;-)
-Clark
On Thu, Dec 14, 2017 at 4:01 PM, Natanael via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Reposting /u/BashCo's post on reddit here, for visibility:
>
> ---8<---------------------------------------------------------------
>
> > Before anyone says 'bits' are too confusing because it's a computer
> science term, here's a list of homonyms [https://en.wikipedia.org/wiki
> /List_of_true_homonyms] that you use every day. Homonyms are fine because
> our brains are able to interpret language based on context, so it's a
> non-argument.
>
>
> This ignores the fact that there exists multiple meanings of bits *within
> the same context*, and that beginners likely can't tell them apart.
>
> Feel free to try it yourself - talk about Bitcoin "bits" of a particular
> value with somebody who doesn't understand Bitcoin. Then explain that the
> cryptography uses 256 bit keys. I would be surprised if you could find
> somebody who would not be confused by that.
>
> Let's say a website says a song is 24 bits. Was that 24 bit audio
> resolution or 24 bit price? Somebody writes about 256 bit keys, are that
> their size or value?
>
> You guys here can probably tell the difference. Can everybody...? Bits
> will cause confusion, because plenty of people will not be able to tell
> these apart. They will not know WHEN to apply one definition or the other.
>
> https://www.reddit.com/r/bitcoin/comments/24m3nb/_/ch8gua7
>
>
>
> _______________________________________________
> 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/20171214/73f8b8ef/attachment-0001.html>

2023-06-07 18:04:38

- reply

📅 Original date posted:2017-07-14
📝 Original message:(copying from GitHub per jonasschnelli's request)
I can understand the desire to keep all reference strings to the nice
14-character version by keeping the data payload to 40 bits, but it
seems to place artificial limitations on the format (year 2048 & 8191
transactions). I also understand that this might be addressed with
Version 1 encoding. But current blocks are not that far from having
8191 transactions.
You could go with a variable-length encoding similar to Bitcoin's
variable ints and gain the benefit of having a format that will work
for very large blocks and the very far future.
Also, the Bech32 reference libraries allow encoding from byte arrays
into the base-5 arrays native to Bech32. It seems like bit-packing to
these 40 bits might be overkill. As an alternative you could have one
bit-packed byte to start:
# First two bits are the protocol version, supporting values 0-3
V = ((protocol version) & 0x03) << 6
# Next two bits are magic for the blockchain
# 0x00 = Bitcoin
# 0x01 = Testnet3
# 0x02 = Byte1 is another coin's magic code (gives 256 options)
# 0x03 = Byte1-2 is treated as the coin magic code (gives 65280 more options)
M = (magic & 0x03) << 4
# Next two bits are the byte length of the block reference
B = ((byte length of block reference) & 0x03) << 2
# Final two bits are the byte length of the transaction index
T = ((byte length of transaction index) & 0x03)
# Assemble into the first byte
Byte0 = V | M | B | T
This gives you up to 3 bytes for each block and transaction reference,
which is 16.7 M blocks, or year 2336, and 16.7 M transaction slots.
Data part: [Byte0][optional magic bytes 1-2][block reference bytes][tx
reference bytes]
So the shortest data part would have 3 bytes in it, with the reference
version 0 genesis coinbase transaction having data part 0x050000.
I know this is a departure from your vision, but it would be much more
flexible for the long term.
Clark