Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

On August 5, 2018 9:11:26 PM UTC, Lautaro Dragan via bitcoin-dev wrote: >Should we actually be using the BIP process to claim a prefix? I recommend against using an op_return prefix, as they allow for transaction censorship. In fact, in our case, where we use an IPFS hash in an op_return, we

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

On Wed, Aug 15, 2018 at 2:24 PM Jude Nelson via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Can a miner identify which transactions came from your software simply by > running a copy themselves? If so, then they can censor your transactions > no matter how you encode them. >

Re: [bitcoin-dev] SLIP-0039: Shamir's Secret-Sharing for Mnemonic Codes

On Fri, Sep 21, 2018 at 11:18 AM Andrew Kozlik via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > We are currently writing a new specification for splitting BIP-32 master > seeds into multiple mnemonics using Shamir's secret sharing scheme. We > would be interested in getting your

Re: [bitcoin-dev] 32-byte public keys in Schnorr and Taproot

On Fri, Aug 9, 2019 at 11:17 AM Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > if we're going to change things, it's perhaps best to do it as cleanly as > possible and also drop that byte. > I personally lean toward just dropping the byte. I like the simplicity

Re: [bitcoin-dev] v3 onion services

Blockchain Commons is using v3 tor authentication for remote clients controlling a full node created using our Bitcoin Standup project (currently only macOS but more platforms coming): https://github.com/BlockchainCommons/Bitcoin-Standup Docs at:

Re: [bitcoin-dev] Deterministic Entropy From BIP32 Keychains

Although I believe that there needs to be a review by a cryptographic engineering expert (ideally Pieter Wuille, who may have to hold his nose to give it a pragmatic review) and I believe such a review will likely some suggest some improvements, I do think something in this area should be done.

Re: [bitcoin-dev] PSBT in QR codes

On Mon, Apr 27, 2020 at 1:44 PM Riccardo Casatta via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > [1] https://github.com/cryptoadvance/specter-diy/issues/57 > So that we don't overwhelm the specter-diy maintainers with topics outside the scope of their project, we are slowly

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

On Thu, May 14, 2020 at 8:30 AM Keagan McClelland via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > It should be therefore a top priority to make the UX of connecting my > mobile LN client to my home full node extremely easy, so that centralised > services can't improve much on

Re: [bitcoin-dev] RFC: Deterministic Entropy From BIP32 Keychains

I agree with the problem statement in this proposal, but not the proposed solution. The challenge of safely securing a seed for a single signature is not insignificant. Blockchain Commons has published procedures that we consider the current best practices for cold storage in a free book at

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

On Fri, May 8, 2020 at 2:00 PM Keagan McClelland via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Perhaps I wasn't explicit in my previous note but what I mean is that > there seems to be a demand for something *in between* a peer interface, > and an owner interface. I have

Re: [bitcoin-dev] Is BIP32's chain code needed?

Leondardo, There are a lot of sub-topics related to your questions that deserve at least some response. I was not involved deeply in bitcoin when BIPs 32/38/39/44/45 emerged, but they were not without some strong differences of opinion and controversy, some of which are reflected in challenges

[bitcoin-dev] Seeking Tech Review of "Learning Bitcoin from the Command Line"

Dear Bitcoin Experts, Learning Bitcoin from the Command Line was one of Blockchain Common 's first offerings, and it remains one of the most popular. Not only has it received on

[bitcoin-dev] Introductory Video on Blockchain Commons UR/QR Tech Now Available

Over the last few years, Blockchain Commons has been working with our Airgapped Wallet Community to produce interoperability specifications to improve Bitcoin wallet usage — and in the future,

Re: [bitcoin-dev] BIP Proposals for Output Script Descriptors

Are there any plans other than `raw` to support time locks in descriptors? Any plans for descriptors offering closer integration with miniscript? All of Blockchain Commons libraries and tools are multisig descriptor centric, and there are many scenarios that require describing time locks: -

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

In the Airgapped Wallet Community we also have been investigating solutions, in particular as current common practice is is reuse the same xpub for all multisigs, for instance [90081696/48'/0'/0'/2']

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

Though I am ACK on that we need to solve the problem of xpub privacy and reuse, I'm NACK on this solution. It is currently too complex and doesn't really solve the problem. I believe that the ultimate solution will be some form of multi-round cryptographic commitment scheme, and as musig

Re: [bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity

Concept ACK. I, in my role as a co-author of the emerging W3C Decentralized Identifier standard and of the BTCR DID method, organizer of the Bitcoin Airgapped Wallet Community ( https://github.com/blockchainCommons/airgapped-Wallet-Community/discussions), and as principal architect of Blockchain

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

I think the key issue here is avoiding xpub key reuse in multisig. Not only in the future with Schnorr, but we need it today! Current common practice by hardware wallets is the 48'/0'/0'/2' derivation for segwit multsig ( e.g.

Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses

As an alternative, you might want to consider LifeHash, which includes a visual indicator as well as a readable fingerprint value. LifeHash is an open source visual hashing algorithm that we use for all our projects. Lifehash has a number of desirable qualities, including high complexity, good

Re: [bitcoin-dev] Proposal for a few IANA mime-types related to Bitcoin

Note that a number of wallet companies are now supporting the UR encoded version of PSBTs, allowing for better QR & Airgap solutions, and also leverage CBOR which is an IETF standard. We have a community of Airgap wallet developers at

Re: [bitcoin-dev] Proposal for a few IANA mime-types related to Bitcoin

On Tue, Aug 31, 2021 at 12:18 PM Peter D. Gray wrote: > QR Codes do not use IANA mime-types. > > If anyone wanted to use UR encoding for PSBT data in a web context (http), > NFC, or email, it would probably be best to discourage them. > > While I can understand the need for UR encoding in

Re: [bitcoin-dev] Announcing bip174.org, a web-based PSBT viewer and editor

On Wed, Aug 25, 2021 at 12:42 PM Alekos Filini via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I'm writing this email to announce the launch of bip174.org, a PSBT > viewer and editor that runs in the browser. > This will be useful. > I, and the larger Airgapped Wallet

Re: [bitcoin-dev] BIP Proposals for Output Script Descriptors

On Thu, Aug 5, 2021 at 8:07 AM Sjors Provoost via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > One thing on my wish list - for this BIP, BIP 88 (Hierarchical > Deterministic Path Templates) or yet another one - is to include a birth > date (minimum block height). E.g.

[bitcoin-dev] New Portuguese & Spanish translations of Learning Bitcoin self-paced course

Blockchain Commons has recently released two translations of our free, self-paced, "Learning Bitcoin from the Command Line" course, into Spanish and Portuguese: - Portuguese Translation: https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/tree/master/pt -

Re: [bitcoin-dev] Bitcoin Legal Defense Fund

On Tue, Jan 11, 2022 at 5:02 PM René Pickhardt via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Will the fund eventually also help to educate developers about the risks > they are facing and which measures can be taken to reduce such risks so > that legal pressure might not even

Re: [bitcoin-dev] Simple step one for quantum

On Fri, Apr 8, 2022 at 4:33 PM Christopher Allen < christoph...@lifewithalacrity.com> wrote: > That being said, it is interesting research. Here is the best link about > this particular approach: > > https://ntruprime.cr.yp.to/software.html > Also I think this is the original academic paper:

Re: [bitcoin-dev] Simple step one for quantum

On Fri, Apr 8, 2022 at 2:36 PM Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I'm not saying I endorse any action at all. Personally I think this is > putting the cart like six and a half miles in front of the horse. > I have to agree that practical

Re: [bitcoin-dev] Future of the bitcoin-dev mailing list

As Bitcoin-Core already uses GitHub, another possibility is to use the new GitHub discussions feature. We increasingly have been using this at Blockchain Commons as everyone is using already using GitHub. We have also created some GitHub actions to backup discussions so that GitHub will not be a

Re: [bitcoin-dev] Ordinals BIP PR

I think this is a good idea, but suggest that the numbers include year and number in the year. We do that for all the research and “wallet improvement proposals” at Blockchain Commons. This way numbers don’t grow huge like EIPs currently do. I might also suggest that the numbers are only

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

On Fri, Jul 1, 2022 at 5:43 AM Alfred Hodler via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I agree with your proposal to use bech32 instead of base58. It looks sound > to me and as you said, the standard would benefit from more compact QR > codes. The most important thing to

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

On Mon, Aug 29, 2022 at 9:12 AM Ali Sherief via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I am aware that business processes are mostly CSV file oriented I disagree that business processes are mostly CSV. Amateur processes maybe, but professional accounting, no. Trying to

[bitcoin-dev] Silicon Salon 3: Call for Presentations On Silicon-Logic-Base Cryptographic Acceleration & New Algorithms

Blockchain Commons will be facilitating Silicon Salon 3 in mid-January, tentatively on January 18th. We will have semiconductor designers, secure hardware developers, and other experts present, and we are calling for other contributors who are interested in making a presentation focused on

Re: [bitcoin-dev] Codex32

An easy but possibly very important tip: If you use only UPPER CASE alpha and numbers in codex32, and avoid most punctuation, it makes QR rendering of it significantly smaller. This is because the QR code to the ISO SPEC, when seeing lowercase, assumes the value is binary, then converts it to a

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

On Fri, Feb 3, 2023 at 3:52 AM Aymeric Vitte via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I think the right way so people don't invent deviant things is to > increase the size of OP_RETURN, I don't get this number of 80B, you can > hardly store a signature (of what?) in there

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

On Sat, Feb 4, 2023 at 9:01 AM Aymeric Vitte wrote: > What is the official bitcoin channel to request the OP_RETURN size change? > (press often mentions that ethereum is good to manage changes and bitcoin a > complete zero. > Here is the simplified version: Most of these changes start with

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

On Sat, Feb 4, 2023 at 12:55 PM Aymeric Vitte wrote: > Thanks Christopher, then I understand the process: > > - I must issue a PR where I switch 80 to another number, even if I am not > a C/C++ expert it looks easy > Yes, this would be an easy PR, at least to start. I suspect that longer-term,

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

I don't have a concrete proposal in mind, I'm just trying to understand various tradeoffs in post-taproot bitcoin in more detail. On Tue, Jan 31, 2023 at 6:07 PM Peter Todd wrote: > > >OP_FALSE > >OP_IF > >OP_PUSH my64bytes > >OP_ENDIF > > What's wrong with OpPush OpDrop? > I'm not sure pro

[bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

All other things being equal, which is better if you need to place a 64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a spent taproot transaction such as: OP_FALSE OP_IF OP_PUSH my64bytes OP_ENDIF I know that the anti-OP_RETURN folk would say “neither.” But if there was no other

Re: [bitcoin-dev] BIP for Serverless Payjoin (AdamISZ)

On Fri, Aug 11, 2023 at 3:29 PM symphonicbtc via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Quick little nit I noticed as well, are you sure base64 encoding is the > best choice for the psk in the URI? You may find that having to urlencode > the special characters in base64 it

Re: [bitcoin-dev] Witness script validation to reject arbitrary data

On May 8, 2023 at 1:16:41 PM, Moth via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > From what I understand, things like inscriptions can only be inserted > between two specific flags - OP_FALSE and OP_IF. Having a validation check > to reject witness scripts that have arbitrary

Re: [bitcoin-dev] BIP for Serverless Payjoin

On Sat, Aug 12, 2023 at 2:20 PM Dan Gould wrote: > am somewhat concerned that some payjoin implementations are written in > JavaScript and would benefit most from a v2 upgrade in order to support > receiving, but no JavaScript ur library exists yet. Perhaps one could be > bound from the rust

Re: [bitcoin-dev] MuSig2 derivation, descriptor, and PSBT field BIPs

On Mon, Jan 15, 2024 at 4:28 PM Ava Chow via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I've also made a change to the PSBT fields BIP where the aggregate > pubkey is included as a plain pubkey rather than as xonly. I think this > change is necessary for to make discovering

Re: [bitcoin-dev] BIP process friction

On Tue, Jan 16, 2024 at 6:43 PM Anthony Towns via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > If people want to use it for bitcoin-related proposals that don't have > anything to do with inquisition, that's fine; I'm intending to apply the > policies I think the BIPs repo should