Re: [bitcoin-dev] BIP Proposal: Wallet Labels Export Format

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

Re: [bitcoin-dev] BIP Proposal: Wallet Labels Export Format

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,

Re: [bitcoin-dev] [BIP proposal] Private Payments

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

Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF

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

Re: [bitcoin-dev] Formal specification of Miniscript in Alloy

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 <

Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses

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

Re: [bitcoin-dev] BIP for segwit compatibility URIs

ter `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 p

Re: [bitcoin-dev] BIP for segwit compatibility URIs

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:[?addr=[,[,]]] The addresses passed as a comma-separated list to the `addr` parameter are in descending order of preference,

Re: [bitcoin-dev] Suggestion for a universal bitcoin value scale

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

Re: [bitcoin-dev] Multi-signature and multi-coin HD wallet in one BIP32 derivation path (new BIP)

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

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

Re: [bitcoin-dev] BIP Proposal: Utilization of bits denomination

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 page on the wiki has been brought up to argue against naming 10,000 satoshi = 1 finney, I would like to support