Re: [bitcoin-dev] BIP process friction

[Christopher Allen via bitcoin-dev]

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 be using, so feel free to open a PR,
> even if you already know I think your idea is BS on its merits. If someone
> wants to write an automatic-merge-bot for me, that'd also be great.
>
> If someone wants to reform the BIPs repo itself so it works better,
> that'd be even better, but I'm not volunteering for that fight.
>

I've no idea how to reform BIPs, but we have a similar problem with the
Blockchain Commons Research (BCR) vs Proposals (BCP), vs. specifications
that are emerging in various other standards groups (IETF, W3C, and we have
desire to submit some of these as BIPs as well).

We do a few things differently, one of which in particular might be useful
for the future of BIPs: we reset the numbers every year. So the first new
BCR (research proposal) for 2024 would be 2024-01. Also, when there is a
major change in an old BCR, we create a new number for it in the new year
it is update.

We also have a concept called "Status", which is a progression that only
moves forward if BCRs are actually implemented with a reference
implementation, and advances further when they have multiple
implementations (and thus are qualified moved over to BCP repo as it is
somewhat stable and no longer "research".). A last form is when a
specification has moved to be controlled by another standards group (such
as a BIP). If only one organization implements a BCR, it will never advance
to BCP.

Some form of Status for BIPs inspired by this concept could track if a BIP
was ever actually implemented by someone, or more ideally, implemented by
multiple people in multiple organizations, ideally in multiple languages.

Here is how we currently do status, and the status of our current
specifications:
https://github.com/BlockchainCommons/Research/blob/master/README.md#status

Each BCR has a status which is indicated by a symbol.
SymbolTitleDescription
❌❌ Withdrawn Of historic interest only. Withdrawn either because never came
into use or proved sufficiently problematic that we do not recommend its
usage in any way.
❌ Superseded Superseded by a newer BCR. We do not suggest implementing as
an output format, but you may still wish to implement as an input format to
maintain backward compatibility.
📙 Research Contains original research or proposes specifications that have
not yet been implemented by us. Offered to the community for consideration.
⭐️ Reference Implementation At least one reference implementation has been
released, usually as a library, and may include demos or other supporting
tools. This specification still remains very open to change because it has
not yet (to our knowledge) been implemented by additional parties.
⭐️⭐️ Multiple Implementations At least two (known) implementations exist,
at least one not by the owner of the reference implementation. Has
demonstrable community support. May still change due to the needs of the
community, but community feedback will be sought.
⭐️⭐️⭐️ Standards Track Typically at least two implementations, and is
considered stable and ready for standardization. Being proposed as a BIP,
IETF Internet Draft, or some other standardization draft format. Will
typically be moved to the BCP repo
. Though changes may still be
made to the specification, these changes will exclusively be to allow for
standardization, and will be conducted with community feedback.
⭐️⭐️⭐️⭐️ Standardized A specification has been standardized as a an IETF
RFC, BIP, or approved by some other standards body.

❌❌ after another status symbol is read, "...but withdrawn" and ❌ is read,
"...but superseded".

-- Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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 derived keys easier. The
> derivation paths for derived keys contain the fingerprint of the parent
> (i.e. the aggregate pubkey) and the fingerprint requires the evenness
> bit to be serialized. So the aggregate pubkey in the PSBT fields need to
> contain that evenness information in order for something looking at only
> the PSBT to be able to determine whether a key is derived from an
> aggregate pubkey also specified in the PSBT.
>

The topic of some challenges in using x-only pubkeys with FROST recently
came up in a conversation that I didn't completely understand. It sounds
like it may be related to this issue with MuSig2.

What are the gotcha's in x-only keys with these multisig protocols? Can you
explain a little more? Any other particular things do we need to be careful
about with x-only pubkeys? I had mistakenly assumed the technique was just
a useful trick, not that it might cause some problems in higher level
protocols.

Thanks!

-- Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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 central point of failure -should be possible to create a static page
archive using GitHub pages (but have not had budget for that).

For instance, here is the GitHub discussion area for wallet developers
working together on Bitcoin wallet interoperability specifications:
https://github.com/BlockchainCommons/Gordian-Developer-Community

— Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Ordinals BIP PR

[Christopher Allen via bitcoin-dev]

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 automatically offered when a
maintainer does not reject it for three days. That way they can focus on
just responding to obvious spam, and if rejected the moderator name is on
it, rather than the current anonymous pocket veto.

— Christopher Allen [via iPhone]

On Tue, Oct 24, 2023 at 3:57 PM Olaoluwa Osuntokun via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> TL;DR: let's just use an automated system to assign BIP numbers, so we can
> spend time on more impactful things.
>
> IIUC, one the primary roles of the dedicated BIP maintainers is just to
> hand
> out BIP numbers for documents. Supposedly with this privilege, the BIP
> maintainer is able to tastefully assign related BIPs to consecutive
> numbers,
> and also reserve certain BIP number ranges for broad categories, like 3xx
> for p2p changes (just an example).
>
> To my knowledge, the methodology for such BIP number selection isn't
> published anywhere, and is mostly arbitrary. As motioned in this thread,
> some perceive this manual process as a gatekeeping mechanism, and often
> ascribe favoritism as the reason why PR X got a number immediately, but PR
> Y
> has waited N months w/o an answer.
>
> Every few years we go through an episode where someone is rightfully upset
> that they haven't been assigned a BIP number after following the requisite
> process.  Most recently, another BIP maintainer was appointed, with the
> hope
> that the second maintainer would help to alleviate some of the subjective
> load of the position.  Fast forward to this email thread, and it doesn't
> seem like adding more BIP maintainers will actually help with the issue of
> BIP number assignment.
>
> Instead, what if we just removed the subjective human element from the
> process, and switched to using PR numbers to assign BIPs? Now instead of
> attempting to track down a BIP maintainer at the end of a potentially
> involved review+iteration period, PRs are assigned BIP numbers as soon as
> they're opened and we have one less thing to bikeshed and gatekeep.
>
> One down side of this is that assuming the policy is adopted, we'll sorta
> sky rocket the BIP number space. At the time of writing of this email, the
> next PR number looks to be 1508. That doesn't seem like a big deal to me,
> but we could offset that by some value, starting at the highest currently
> manually assigned BIP number. BIP numbers would no longer always be
> contiguous, but that's sort of already the case.
>
> There's also the matter of related BIPs, like the segwit series (BIPs 141,
> 142, 143, 144, and 145). For these, we can use a suffix scheme to indicate
> the BIP lineage. So if BIP 141 was the first PR, then BIP 142 was opened
> later, the OP can declare the BIP 142 is BIP 141.2 or BIP 141-2. I don't
> think it would be too difficult to find a workable scheme.
>
> Thoughts?
>
> -- Laolu
>
>
> On Mon, Oct 23, 2023 at 11:35 AM Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Everything standardized between Bitcoin software is eligible to be and
>> should be a BIP. I completely disagree with the claim that it's used for
>> too many things.
>>
>> SLIPs exist for altcoin stuff. They shouldn't be used for things related
>> to Bitcoin.
>>
>> BOLTs also shouldn't have ever been a separate process and should really
>> just get merged into BIPs. But at this point, that will probably take
>> quite a bit of effort, and obviously cooperation and active involvement
>> from the Lightning development community.
>>
>> Maybe we need a 3rd BIP editor. Both Kalle and myself haven't had time
>> to keep up. There are several PRs far more important than Ordinals
>> nonsense that need to be triaged and probably merged.
>>
>> The issue with Ordinals is that it is actually unclear if it's eligible
>> to be a BIP at all, since it is an attack on Bitcoin rather than a
>> proposed improvement. There is a debate on the PR whether the
>> "technically unsound, ..., or not in keeping with the Bitcoin
>> philosophy." or "must represent a net improvement." clauses (BIP 2) are
>> relevant. Those issues need to be resolved somehow before it could be
>> merged. I have already commented to this effect and given my own
>> opinions on the PR, and simply pretending the issues don't exist won't
>> make them go away. (Nor is it worth the time of honest people to help
>> Casey resolve this just so he can further try to harm/destroy Bitcoin.)
>>
>> Luke
>>
>>
>> On 10/23/23 13:43, Andrew Poelstra via bitcoin-dev wrote:
>> > On Mon, Oct 23, 2023 at 03:35:30PM +, Peter Todd via bitcoin-dev
>> wrote:
>> >> I have _not_ requested a BIP for OpenTimestamps, even though it is of
>> much
>> >> wider relevance to

Re: [bitcoin-dev] BIP for Serverless Payjoin

[Christopher Allen via bitcoin-dev]

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

There is some progress here, including our reference library in Typescript
for dCBOR and UR-based Envelope, but hopefully we will expand soon to offer
it in reference libraries, though some will have to be wasm of our rust
code.

I've heard that there are some wallets using URs written Javascript, but
they have not announced open source libraries yet.

-- Christopher Allem
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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 impacts readability and adds a layer of
> complexity if a human wanted to extract the psk from the URI for some
> reason. I suggest using something like [base64url](
> https://datatracker.ietf.org/doc/html/rfc4648#section-5) which modifies
> base64 slightly to be more suited to this purpose.


Yes, the URI version of base64 is better.

>
However, If you plan to display these via QRs, either will double the
density of the QR as QR libraries treat them as binary data (like hex of
hex data). Thus you may want to use UR encoding, which is what over a dozen
bitcoin wallets use to encode PSBTs. URs are very efficient with QRs, and
have the optional benefit that if the data carried becomes too large, they
can be animated. The have other advantages.

* A top level link about URs:
https://github.com/BlockchainCommons/crypto-commons/blob/master/Docs/README.md#uniform-resources-urs

* About the base64 encoding with QRs problem:
https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-003-uri-binary-compatibility.md

* The base UR tech spec:
https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md

* List of bitcoin wallets using UR for PSBTs:
https://github.com/blockchaincommons/gordian-developer-community#urs

* List of UR libraries:
https://github.com/BlockchainCommons/crypto-commons#bc-ur

Let me know if you’re interested.

— Christopher Allen

>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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 data between these two flags
> could be used to reject inscriptions while still allowing all the benefits
> of taproot. This will prevent people from overloading the network with txns
> geared solely for ordinals and brc-20 tokens.
>

Unfortunately, there are many other ways to “inscribe” other than that
particular trick.

>
> Is there a reason such a validation check is a bad idea? We already have
> OP_RETURN to store arbitrary data that is limited to 80kb. Was it an
> oversight that arbitrary data can be inserted between OP_FALSE and OP_IF
> when the size limit for witness scripts was lifted as part of taproot?
>

There have been some of us that had hoped for a slightly larger OP_RETURN
such that we can store a tagged root of a hash-tree (~128-512 bytes). For
instance, open time-stamps, ION, and my own privacy-focused Gordian
Envelope (https://www.blockchaincommons.com/introduction/Envelope-Intro/),
all consolidate large sets of proofs into a hash, which we use for L2
proofs-of-inclusion. My own preference is that the size can be large enough
so you can store the hash, optionally have a signature on it, and have a
few bytes for self-describing data (we like CBOR as it is quite small).

All of us held off for years asking for larger OP_RETURN or standardizing
on a pay-to-contract BIP for the techniques we do use because of objections
to putting anything on-chain. But now we are dismayed by the inscription
technique that freeloads on the network mempool, the validation network,
and volunteer unpruned full nodes.

For instance, I host an alternative explora instance (the source code base
used by blockstream.info), offering it publicly via Tor so that there is
more than a single server offering its details. Inscriptions combined with
DOS attacks on Tor is making it more expensive for me to host and maintain
this free privacy service.

There was a recent thread discussing raising the limit on OP_RETURN
https://github.com/bitcoin/bitcoin/issues/27043

Here is an old relevant thread from open time-stamps:
https://github.com/opentimestamps/python-opentimestamps/pull/14

I’m not sure what the solution is. I feel like I’ve been a good neighbor
for some time on this topic, always recommending minimal on-chain data, and
now I feel frustrated with this free-rider problem.

— Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Codex32

[Christopher Allen via bitcoin-dev]

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 two byte value. If instead, the
codex32 is all upper, and it uses only the 45 allowed characters (see
https://www.thonky.com/qr-code-tutorial/alphanumeric-table) , it will leave
it single byte and try to compress it. Of course it doesn’t compress well,
but that is OK because it at least didn’t double the size first.

See our research on this topic at
https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-003-uri-binary-compatibility.md

A superior QR codec can do better (see our
https://github.com/BlockchainCommons/QRCodeGenerator or
https://www.nayuki.io/page/qr-code-generator-library) but many platforms
and more basic QR codecs will double the size of the QR if you have any
lower case.

— Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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, you'd need to draft some assistance to make it turn on/off
from when the bitcoin daemon is initialized. But that could wait until the
conversation has progressed some.

The harder part will be writing the initial comment, where you should
carefully explain the rationale, link to some existing conversations, try
to point out in advance the obvious objections and rationale despite them,
and explain your particular choice of number — 520 because that is a
similar limit in taproot? Some multiple of hash+signature+metadata to
satisfy others (that still might not be satisfied by any choice).

> - I  must stay calm and answer all outstanding concerns about this trivial
> change
>
> - Since I am not as clever as the bitcoin devs I must be ready to revise
> my PR at any time
>
> - This could lead for the change to be from 80B to 82.xB where x comes
> from a non understandable crypto formula
>
> - I must evangelize the change worldwide
>
> - Once accepted, I must collude (pay) with the nodes/miners so they update
> at a subtile block height decided by the community
>
That is true for forks, but I don't think this is a fork. It might require
resolving some mempool issues (for instance for mining pools). But for it
to become non-optional, you'll need to demonstrate that miners and full
nodes have turned it on. Thus that is more a conversation than "collusion
(pay)".

> And then I must pray that the PR does not survive myself
>
> Looks like a pretty straight forward process.
>
I've seen worse. I co-authored TLS 1.0 (6 years) and DID 1.0 (5 years).

> I am on this list since quite some time, so, seriously, this change is
> needed, or, as I said before, deviant behaviours will happen, because the
> "witness trick" or others do not work at all, and are clearly similar to
> ethereum messy stuff
>
You have at least Concept ACK from me! ;-)

-- Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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 discussions like these, but then are moved
concretely to a PR to bitcoin-core with the code changes (in this case
there is no fork so pretty easy) and an introductory comment pointing to
discussions elsewhere.

The conversation will also move to the PR itself. Part of the challenge now
is getting review of your PRs - you’ll need to evangelize some and/or have
social capital in the bitcoin community to get sufficient ACKs to your PR
(and some NACKs which you will calmly addres), and someone will likely
point something out you missed, so you revise the PR.

At some point hopefully there looks like all reasonable objections have
been addressed.

If there is enough interest and few objections there will be discussions by
the community & maintainers to merge it. It is this last part that isn’t
very transparent, especially for even a good proposal. The maintainers,
based on their sense of the community’s interest and consensus, must choose
when to say it is ready, and then decide when and to which release they
wish to merge it.

They often start by requesting you to revise your changes to be off by
default, and be turned on as an option for a specific release. Often PR
contributors know this is coming and include it.

Even once it is released, this type of change can only happen after
sufficient miners and nodes update to the release and turn it on. If
sufficient do, then the maintainers evaluate when to have the feature on by
default.

These articles offers more perspective:

   -

   https://unchained.com/blog/contributing-bitcoin-core-patience/
   -


   
https://jonatack.github.io/articles/how-to-contribute-pull-requests-to-bitcoin-core
   -

   https://medium.com/@amitiu/onboarding-to-bitcoin-core-7c1a83b20365

— Christopher Allen

>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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 and not the "what" if the
> "what" is a hash for example
>

Updating the size of OP_RETURN to support a hash (or two), a signature, and
maybe a few more bytes for metadata, would be very helpful in a number of
scenarios. It is still a limit but a reasonable one. Otherwise, I think
we'll have a lot more inscription-style scenarios.

-- Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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 or con of either. I just saw that proposal above recently.


> Also, it is incorrect to say that OpReturn outputs "clog UTXO space". The
> whole point of OpReturn is to standardize a way to keep such outputs out of
> the UTXO set. There is the 75% discount to using witness space. But
> considering the size of a transaction as a whole using taproot instead of
> OpReturn doesn't save much.
>

There are OP_RETURN tricks in production that do clog UTXO space. I was
trying to avoid consideration of those by just saying to compare apples vs.
apples, by presuming that any form of these transactions holding the 64
bytes is a spent transaction.

Finally, _64_ bytes is more than a mere 32 byte commitment. What specific
> use case do you actually have in mind here? Are you actually publishing
> data, or simply committing to data? If the latter, you can use ECC
> commitments and have no extra space at all.
>

I chose 64 bytes for this exercise, as I know there are tricks hiding 32
bytes as keys. As almost every op_return live out there is >32 bytes, I
wanted an example that could be a signature, two hashes, a hash plus some
metadata, etc. I also considered 96 bytes (for instance a hash and a
signature), but as that doesn't fit into OP_RETURN's 80 bytes, that choice
prohibits comparing the different approaches side-by-side.

To come back to my question another way, if you ignore the people who say
"never put anything except data facilitating coin transactions into the
bitcoin blockchain", but if you also are not trying to use the bitcoin
blockchain as a world database (ala ETH), what is the most pragmatic way to
do so that minimizes any potential harm? The answer pre-taproot was
OP_RETURN. What is it now?

-- Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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 choice for a particular protocol, such as a timestamp or a
commitment, which is better? Or is there a safer place to put 64 bytes that
is more uncensorable but also does not clog UTXO space, only spent
transaction `-txindex` space?

My best guess was that the taproot method is better, but I suspect there
might be some who disagree. I'd love to hear all sides.

-- Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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
silicon-logic-based cryptographic acceleration or support for new
functionality such as Multi-Party Computation (MPC) leveraging hardened
semiconductor-based security.

Our Silicon Salons are an ongoing series of virtual salons intended to
bring together digital wallet developers, semiconductor manufacturers, and
academics. The objective:

   - *To ensure that the next generation of cryptographic semiconductors
   meets everyone’s needs, advancing the entire cryptography industry.*
   - *Reduce is a gap between wallet requirements and semiconductor
   development, between academic research and real-world practice; we want to
   bridge it.*

Some presentations lined up so far are:

   - In pursuit of an open Secure Element: What are the elements that make
   a semiconductor more or less “open”, and what is really important?
   - Architectural considerations in creating a semiconductor for the
   future of MPC.

See https://www.siliconsalon.info/ for our salons to date. Silicon Salon 3
will continue these topics.

If you are interested in making a presentation at Silicon Salon 3,
please contact
us with a proposal. Include the following:

   1. The title.
   2. A summary of what your presentation will be about.
   3. A summary of how that relates to silicon-logic-based cryptographic
   acceleration & new functionality and/or the general topic of integrating
   cryptography into new semiconductors. Note that this can be a discussion of
   capabilities from the point of view of a semiconductor manufacturer, of
   needs from a wallet manufacturer, or other discussions from someone in the
   broader decentralized community.
   4. The name of the presenter(s).
   5. A description of who they are and how they or their company have the
   expertise, capability, or reach to benefit the Silicon Salon conversation.

Final presentations should be about five minutes long, supported by a slide
deck or some equivalent, which you will present in our Zoom salon on the
date of the salon.

Please note the following deadlines for Silicon Salon 3 proposals and
contributions:

   - *December 23* - Final date for submission of proposals.
   - *January 4* — Blockchain Commons selection of proposals.
   - *January 11* — Submission of draft slide decks to Blockchain Commons
   for any comments.
   - *January 16* — Submission of final slide decks to Blockchain Commons
   for inclusion in post-event web pages.
   - *January 18* — Presentation at Silicon Salon 3.
   - *January 25* — Blockchain Commons finalization of website release of
   the video, selected Q&A, transcripts, and final presentations.

Also, please note that the January 18th date is tentative. We are checking
with likely participants for conflicts, and ensuring that the holidays
won’t cause too much conflict. If it moves, then the January deadlines will
move accordingly.

Thank you for your interest in Silicon Salon 3 and the future of
semiconductor integration with cryptography! If you have any questions or
want more information, please email us at t...@blockchaincommons.com.

Even if you do not want to present, please Save the Date of January 18th,
2023, so that you can participate in the conversation. We’ll make an
announcement as soon as we’ve finalized the date and have an Eventbrite
page available for signups.

Thank you to our sustaining sponsors who make Silicon Salon possible:
Bitmark, Chia, Cramium Labs (a subsidiary of CrossBar), Foundation, Proxy,
and Unchained Capitol. We are also seeking additional sponsors. Mail us at
t...@blockchaincommons.com or become a sponsor on GitHub
 and let us know it’s to
support Silicon Salon!

-- Christopher Allen, Principal Architect & Executive Director, Blockchain
Commons
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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 do my business accounting
with CSV files from various exchanges is PITA.


> so you can make a statement akin to BIP174 in the Goal 2 BIP, that expects
> the medium of exchange to be in files ending in .csv. I wouldn't mind if
> you require .csv file extension in a BIP for Goal 2. But such a statement
> is not appropriate in the Goal 1 BIP which is only concerned with the
> wallet label format itself.


I too would like to see some separation of layers here, as there are other
possible output formats. Maybe expanding on another use case for this data
would help.

I've been working with @nochiel  on export
to a Plain-Text
Accounting  friendly format,
initially the beancount
python app : (our prototype is
current at /beancounter.py but it is being refactored into new repo).

Basically what the final tool will do is: given a descriptor, get any
transactions for that descriptor from a random explora via Tor (initially
ours and Blockstream's), and then get price information from a random
Spotbit price server via Tor (initially just ours, but seeking more hosts),
and export a beancount compatible file.

```

python app.py beancount
"wpkh(tpubD9hudZxy8Uj3453QrsEbr8KiyXTYC5ExHjJ5sNDVW7yKJ8wc7acKQcpdbvZX6dFerHK6MfVvs78VvGfotjN28yC4ij6nr4uSVhX2qorUV8V/0/*)"
Outputs: spotbit.beancount

2008-10-31 commodity BTC
  name: "Bitcoin"
  asset-class: "cryptocurrency"

2018-04-02 open Assets:BTC BTC
2018-04-02 open Liabilities:Cash:USDT USDT

2018-04-02 * "tb1qcrekknrspx28t9vl53ltsag5gqgqdj066ydf75" "Transaction
hash: 2a2f7f24761fa54cb6e559efea5678415d9cbbabc42e6a4e2ce463ee3c446230"
Assets:BTC 1. BTC { 6935.16 USDT }
Liabilities:Cash:USDT - 6935.16 USDT

2018-04-02 * "tb1q45whzx3emntntnpzjdx3gzj6z5cgxakkg7s3sa" "Transaction
hash: 387123efcaa707759a4af8159cb1309fae86b793d26b5fd8bba42637852dde89"
Assets:BTC - 0.36300616 BTC @  6935.16 USDT
Liabilities:Cash:USDT 2517.51 USDT

2018-04-02 * "tb1qgv5484m83e2mzz3n8tf4snvnwj5qgqgampnhvv" "Transaction
hash: 387123efcaa707759a4af8159cb1309fae86b793d26b5fd8bba42637852dde89"
Assets:BTC - 0.63699243 BTC @  6935.16 USDT
Liabilities:Cash:USDT 4417.64 USDT

2018-04-02 * "tb1q45whzx3emntntnpzjdx3gzj6z5cgxakkg7s3sa" "Transaction
hash: 387123efcaa707759a4af8159cb1309fae86b793d26b5fd8bba42637852dde89"
Assets:BTC 0.36300616 BTC { 6935.16 USDT }
Liabilities:Cash:USDT - 2517.51 USDT
```

I can then use the beancount cli app (or it's fava webapp) to easily add
other details to this file to do my bitcoin accounting (and any other
accounting I need). In particular, as beancount support lots, it solves a
problem for me with US taxes which is unrealized capital gain (I get 1 BTC
from donor at $20K, the price goes up to $30K and I pay it to an engineer,
my BTC balance is 0 but my unrealized capital gain for US tax purposes  is
$10K).

More ideally, if there were additional details that I could merge in from
my wallet export, such as payer and payee, notes, etc. it would make my
accounting much easier.

Thus I'd like to see an easier and interoperable way to merge these details
(my account details from an Esplora and price details from Spotbit), with
what my different wallets may (or may not) have available.

I hope that this might inspire some ideas from the people working on this
wallet export format.

-- Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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 get more compact QR codes is to not use
lowercase letters, and certain other characters, as if you can avoid them
the QRs will auto-compress.

It happens that the core of bech32 works if all caps, and you are careful
with the human readable portion.

See
https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-003-uri-binary-compatibility.md
for more details, but a big offender is base64 which not only doesn’t
auto-compress but also can trigger binary mode that almost doubled the size
of the QR.

We have a number of standards & libraries focused on bitcoin QRs, including
support of animated QRs for things like PSBTs, but if you care about QR
size you should take a look at the techniques we use our swift library
https://github.com/BlockchainCommons/QRCodeGenerator which are also in
https://www.nayuki.io/page/qr-code-generator-library.

Basically both of these libraries support “optimal encoding using segments”
that if they encounter a set of characters that must be encoded in binary
(In particularly $ % * + / :) that would in most default platform QR
implementations  cause the entire QR to double in size. Instead will only
encode the small segment as binary, letting the rest of the QR leverage
auto-compression.

If your are interested in our other Airgap QR and TorGap UR efforts, see
our video from last year:
https://youtu.be/RYgOFSdUqWY We have much more on the way, including NFC
encrypted Airgap & crypto-request/response flows.

I’d love to see proposals for various payment and invoice QRs that leverage
these wallet interoperability standards we have been offering. Let us know
if you are interested, or join discussions at
https://github.com/BlockchainCommons/Airgapped-Wallet-Community

— Christopher Allen, Blockchain Commons

>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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:

https://eprint.iacr.org/2021/826.pdf


>
— Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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 quantum-attacks are like fusion, human-level
AI, and nanotechnology — always 20 years away. In addition, several
reported approaches to quantum-attack resistance have fallen, and more will
fall in the next “20 years”.

That being said, it is interesting research. Here is the best link about
this particular approach:

https://ntruprime.cr.yp.to/software.html

Blockchain Commons can’t offer to fully fund this research, but if others
do we’d be glad to contribute a small grant.

— Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Legal Defense Fund

[Christopher Allen via bitcoin-dev]

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 arise in the first place?
>

We (Blockchain Commons) have also started a project to document
best-practices of pseudonymous development. A work-in-progress but an
important part of our 2022 roadmap. Led by Namcios & myself, but we welcome
issues, review & contributions!

https://github.com/BlockchainCommons/Pseudonymity-Guide

— Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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
   - Spanish Translation:
   
https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/tree/master/es

Learning Bitcoin from the Command Line teaches about Bitcoin development
starting with bitcoin-cli and moving on to using computer languages to
access the RPC API. We’ve always intended that it provide a pathway for
developers to join the broader Bitcoin ecosystem, and we’ve seen personal
success toward that goal, with most of our international interns getting
their start with our course, and with many of them having since found
employment in the field.

Having more educated people in the field not only helps everyone looking
for developers, but it also will make it that much easier for us to make
the next big transition, such as the Taproot transition that we’re
currently working on.

With 460 million native speakers of Spanish and 230 million native speakers
of Portuguese, and with 29 different countries where one or both is an
official language, we think these new translations will considerably widen
the scope of Learning Bitcoin’s coverage and invite many new developers to
work together with all of us on Bitcoin, using the international language
of computer code. Of course, this year’s decision by El Salvador to adopt
Bitcoin as an official currency makes it even more obvious why these sorts
of translations are important.

Here’s what’s next for Learning Bitcoin from the Command Line.

   1. Learning Bitcoin from the Command Line v3.0

Our current iteration of Learning Bitcoin from the Command Line is now a
full year old, so we want to update it to talk about the newest Bitcoin
work, including Taproot, Schnorr signatures, miniscript, and more. Our
current outline for v3.0 is found here (though it’s likely to change some
as we dive fully into the latest bitcoin-core releases):

https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/TODO-30.md

We’d love your expertise on anything you think we’re missing, or getting
wrong, for the v3.0 update. Please feel free to respond here or write us an
issue, either telling us of any problems with the current course (including
things that have just gotten out of date) or things that we should have in
v3.0 that we’re not currently outlining.

https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/issues

   1. Learning Bitcoin from the Command Line Seminars

We are considering offering some brief, weekly seminars in 2022, looking at
individual sections of Learning Bitcoin from the Command Line and answering
questions. If this interests you, or you’d like to help support it, please
let us know.

Thank you to everyone who worked on the translations of Learning Bitcoin:
Ian Culp, Maxi Goyheneche, Said Rahal, César A. Vallero, and Javier Vargas
for our Spanish translation; Namcios, Korea, Luke Pavsky, and hgrams for
the Portuguese translation.

To continue this work, we are looking for monthly patronage to support
Learning Bitcoin. If you think increasing the pool of Bitcoin developers is
important, please consider becoming a patron of Blockchain Commons, and let
us know it’s because of your interest in this course.

https://github.com/sponsors/BlockchainCommons

Thanks for your interest!

-- Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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 animated QR
> codes, I don't think any other use-case could justify introducing
> a new word list (ByteWords), a unique checksum algo (Xoshiro256),
> fountain codes (Luby Transform) and CBOR... just to wrap a few k
> of binary.
>
> I do love CBOR though. It's the best.


UR is more than just a QR, it is URL conformant text that is optimized for
compression in QRs.

In particular, take a look at the explanation of the UR format at the 20m0s
mark in this video:
https://youtu.be/RYgOFSdUqWY

The rest of the video explains why we made the choices we did. We wanted to
leverage existing standards, but there were too many compromises expecially
give QR requirements. See the section on “Why Another Standard” in our
overview at
https://github.com/BlockchainCommons/crypto-commons/blob/master/Docs/ur-1-overview.md#why-another-standard

Note that the UR specification just is not just being adopted by wallet
vendors, but also a number of online services / transaction coordinators
that only have access watch-only keys. These services can then do a
crypto-request for the airgapped wallet to sign the PSBT.

— Christopher Allen

>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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
https://github.com/BlockchainCommons/Airgapped-Wallet-Community

…and libraries at
https://github.com/BlockchainCommons/crypto-commons#urs

We’d love for you to register UR as well, maybe as bitcoin/psbt+ur

Can you bring this up in our community for further discussion?
https://github.com/BlockchainCommons/Airgapped-Wallet-Community/discussions

Thanks!

— Christopher Allen [via iPhone]

On Tue, Aug 31, 2021 at 11:41 AM Peter D. Gray via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi list!
>
> I am proposing to register the following MIME (RFC 2046) media types with
> the IANA:
>
>
> bitcoin/psbt
>
> - aka. a BIP-174 file, in binary
> - does not make any claims about signed/unsigned status; lets leave
> that to the file
>
> bitcoin/txn
>
> - aka. wire-ready fully-signed transaction in binary
>
> bitcoin/uri
>
> - aka [BIP-21](
> https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki)
> - could be just a bare bech32 or base58 payment address
> - but can also encode amount, comments in URL args
> - potentially interesting as a response to 402 - Payment required
>
>
> Other thoughts
>
> - some mime-types are proposed in BIP-71 but those are unrelated to above,
> and never
>   seem to have been registered
>
> - for those who like to encode their binary as base64 or hex, that can be
> indicated
>   as "encoding=hex" or "encoding=base64" in the optional parameters, just
> like
>   "text/plain; encoding=utf-8" does. However, the default must be binary.
>
> - although the above are useful for web servers, they are also useful
> elsewhere and I
>   intend to use them in NFC (NDEF records) where a shorter length is
> critical.
>
> - I have no idea how easily IANA will accept these proposals.
>
> - current approved mime types:
> https://www.iana.org/assignments/media-types/media-types.xhtml
>
> Thoughts?
>
> ---
> @DocHEX  ||  Coinkite  ||  PGP: A3A31BAD 5A2A5B10
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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 Community would love to see you add
output of UR-based animated QRs to your website. An increasing number of
advanced hardware & software wallets are now supporting Airgapped UR/QR
PSBT signing.
https://github.com/BlockchainCommons/Airgapped-Wallet-Community

You can see a video example of this in action between the Foundation
Devices hardware wallet & Blue Wallet in this video, at the 17m48s mark:
https://youtu.be/bYeoCBAUDYs

The easiest to do is output these UR QRs from your site, as there are
multiple libraries in multiple languages to support them, but I also know
that there are some major web-based transaction coordinator services also
planning to add Browser scanning of PSBTs on laptops with cameras as well.

— Christopher Allen

>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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 aesthetics, a printer-friendly (CMYK) color gamut and
robustness when transformed to grayscale.

* [LifeHask Overview and links to reference code](
https://github.com/BlockchainCommons/lifehash)

* [LifeHash Explainer on YouTube](
https://www.youtube.com/watch?v=cu0K__KLxKo)

* [Our LifeHash UX best practices - The Object Identity Block](
https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2021-002-digest.md#object-identity-block
)

-- Christopher Allen
   Principal Architect, Blockchain Commons
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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. tr([m/86'/0'/0']xpub.../{0-1}/*)>709631
>
> And then of course there's the gap limit. Perhaps we just need a
> "metadata" format to go along with descriptors to track the birth data, gap
> limit and anything else you need (nonce collection for musig2 setup?). E.g.
> a simple dictionary: tr([m/86'/0'/0']xpub.../{0-1}/*){dob:709631,gap:1000}
>

The UR standards we use in Airgap Wallet Community for interoperability
(currently used by a number of recent wallets for airgap PSBT via animated
QR) leverages CBOR's tagging capability, and thus explicitly supports
metadata. In particular the spec reference code support optional seed
birthdate as some wallet vendors really wanted that metadata.

It would be trivial to support it for hd-keys, and if gap is important, we
could also easily add this to the hd-keys spec as well. That is part of the
reason why use CBOR for the underlying binary encoding is tagging lets
us add important metadata. The UR standards themselves adds to binary CBOR
encoding a very efficient transport via QRs or URLs that leverage native QR
compression.

See:
* Video: [Blockchain Commons Technology Overview](
https://www.youtube.com/watch?v=RYgOFSdUqWY)
* Articles: [URs: An Overview](Docs/ur-1-overview.md)
  * [A Guide to Using URs for Key Material](Docs/ur-2-keys.md)
  *[A Guide to Using URs for SSKRs](Docs/ur-3-sskrs.md)**
  * [A Guide to Using UR Request & Response](Docs/ur-99-request-response.md)
* Specs:
  * [Research 2020-05 - Uniform Resources (UR): Encoding Structured Binary
Data for Transport in URIs and QR Codes](
https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md
)
  * [Reserach 2020 - UR Type Definition for Hierarchical Deterministic (HD)
Keys](
https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-007-hdkey.md
)

If you have questions about these, drop by the Airgapped Wallet Community
on GitHub at https://github.com/BlockchainCommons/Airgapped-Wallet-Community

-- Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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:

   - [Designing Multisig for Independence & Resilience](
   https://github.com/BlockchainCommons/Gordian/blob/master/Docs/Multisig.md
   )

— Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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, other cryptocurrency applications, such as Ethereum
wallets, and other cryptography aps, such as chat systems, key-management
programs, and more. Our goal is to improve the independence, security, and
resilience of cryptographic systems.

We recently put together an introductory video to talk about our
initiatives:

* https://www.youtube.com/watch?v=RYgOFSdUqWY

We've been working on encoding methods, improved sharding methods, better
user interfaces, partitioned architectures, multisig patterns and more.
It's all in there!

We've also begun work on new documentation for developers, to help
introduce some of our specifications. That begins with a look at Uniform
References, our typed method for encoding binary data in plain-text strings
that are also well-formed URIs suitable for QR.

* UR Overview —
https://github.com/BlockchainCommons/crypto-commons/blob/master/Docs/ur-1-overview.md
* A Guide to Using UR for Key Material —
https://github.com/BlockchainCommons/crypto-commons/blob/master/Docs/ur-2-keys.md

(We've got a few more docs coming soon on using URs interactively and for
animated PSBTs and shamir seed shares.)

If anyone is interested in talking about these specifications and other
technologies more, I'm always enthusiastic to do so, here or in the Airgapped
Wallet Community Discussions
.
I'm also enthusiastic to get more developers on board in using these
technologies, joining folks like Fully Noded, AirGap Vault, BlueWallet,
Cobo Wallet, and Sparrow Wallet — interoperability takes a community!

For further details, I've included a set of links for the topics covered in
the video.

Christopher Allen
President, Blockchain Commons

COMMUNITY LINKS

* Blockchain Commons Website — https://www.blockchaincommons.com/
* Blockchain Commons Repos — https://github.com/BlockchainCommons
* Airgapped Wallet Community —
https://github.com/BlockchainCommons/Airgapped-Wallet-Community

BLOCKCHAIN COMMONS TECHNOLOGIES

* ByteWords —
https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-012-bytewords.md
* LifeHash — https://github.com/BlockchainCommons/bc-lifehash
* SSKR —
https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-011-sskr.md
* Uniform Resources (URs) —
https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md
   * Registry of UR Types —
https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-006-urtypes.md

RELATED LIBRARIES

* ByteWords —
https://github.com/BlockchainCommons/crypto-commons#bc-bytewords
* LifeHash — https://github.com/BlockchainCommons/crypto-commons#lifehash
* SSKR — https://github.com/BlockchainCommons/crypto-commons#bc-sskr
* UR — https://github.com/BlockchainCommons/crypto-commons#bc-ur

SECURITY ARCHITECTURES & METHODS

* #SmartCustody — https://www.smartcustody.com/
* TorGap — https://github.com/BlockchainCommons/torgap
* Designing Multisigs for Independence & Resilience -
https://github.com/BlockchainCommons/Gordian/blob/master/Docs/Multisig.md

EDUCATION
* Learning Bitcoin from the Command Line 2.0 -
https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line

APPLICATIONS MENTIONED

* Gordian Guardian —
https://github.com/BlockchainCommons/GordianGuardian-iOS
* Gordian Server — https://github.com/BlockchainCommons/GordianServer-macOS
* Gordian Wallet — https://github.com/BlockchainCommons/GordianWallet-iOS
* Keytool — https://github.com/BlockchainCommons/keytool-cli
* LetheKit — https://github.com/BlockchainCommons/lethekit
* Seedtool — https://github.com/BlockchainCommons/seedtool-cli
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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 threshold signatures with
Taproot/Schnoor also require multi-round scheme, we should start thinking
now about how maybe we can leverage that work to address this problem as
well. However, I'm not a cryptographer and don't have a specific solution
in this area to offer.

In the meantime, there are some possible measures we can take as new best
practices. This is not a formal list, and I'm open to other suggestions,
but each are currently relatively easy and are functional with some
existing wallets that CAN support state. Let us get it right with stateful
wallets, then we can return back to better best practices for stateless
wallets like Trezor, Ledger, etc.

A) We should accept that users must to backup their multisig account maps
(descriptor with only xpubs) along with their cosigner key material to be
able to recover funds. In the Airgap Community we make this very easy with
a simple UR code that works efficiently as a QR. I personally keep multiple
copies of this account map in multiple locations, as it is less of a risk
(mostly privacy) if one of the locations is compromised.

B) Cosigner wallets and transaction coordinator services should not share
the master xpub, only the derived co-signer xpubs required for that
specific account. Currently too many libraries, wallets and coordinators
only function if they get the master xpub — these should be updated to not
require them.

C) In many current wallets, the master xpub fingerprint is required — that
master fingerprint is also a privacy risk and should not be used. For
instance, the current practice of offering what the Airgap Community calls
a `crypto-hdkey` [604b93f2/48'/1'/0'/2'] with the master fingerprint root,
could instead be to only offer a single parent fingerprint [f93749a7/2']
from that grandparent master key. Thus different fingerprints can be
offered for each account, and only the signer knows the actual master
fingerprint and its children.

D) Given C, when creating a new multisig account, a transaction coordinator
may request a specific master fingerprint and/or a fixed 48' derivation
xpub from a cosigner wallet, but these are only hints. If it gets back a
different fingerprint or derivation, it should accept it. In the case of
the Airgap Community's specifications, in our "crypto-request" we actually
specifically allow for wildcard requests which makes this easy and
explicit. Yes, only stateful signers can know to return an xpub something
other than the fingerprint  and m/48'/1'/0'/2' default, but a transaction
coordinator should accept it if it receives it.

E) Transaction coordinators should send the cosigner "policy" (basically
the multisign descriptor without any keys in it) along with any request to
derive a new xpub for that new account. Stateful wallets can use this
policy to know later if they are asked to sign a PSBT that does not match
this policy.

F) Transaction coordinators should also send the final "account map" to all
the cosigner wallets as a best practice as well. This would replace the
temporary "policy" in D. If a PSBT request to sign using a key doesn't
match the original account map, the cosigner wallet can reject it.

These best practices don't solve the problem with stateless wallets like
Trezor, but they are possible now with the new generation of multisig
hardware and software wallets, such as Foundation Devices, CoboVault,
Sparrow, Bluwallet and my Gordian reference wallet tools. We have available
NOW working interoperable specifications, reference code, and example apps
that support these best practices, and some are already supported by
multiple wallets in the Airgapped Wallet Community hosted by Blockchain
Commons at https://github.com/blockchainCommons/airgapped-Wallet-Community.

I've put a copy of this rough proposal in our Airgapped Wallet Community
discussion area if you have suggestions or alternative best practices.

[Initial proposal for best practice to avoid XPUB reuse in multisig account
creation](
https://github.com/BlockchainCommons/Airgapped-Wallet-Community/discussions/53
)

-- Christopher Allen, Blockchain Commons
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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.
[90081696/48'/0'/0'/2']xpub6DYLEkDfCdHzh5FHGHDJksQvFqu6kYANa1sfo6fA8n5ZWkSwyCRVVzyq9LY2eNGB6T9BKDeGJp2ZarjRZHd7WB95nSaFEDhFMK6zSV6D49b
) is the only one used for ALL multisigs offered by that hardware wallet.

As Pieter said, leveraging a HD path parameters can help, but we need a
better, less reusable path for the index.

I personally suggest a simpler solution, which is to create an index using
a PBKDF of the Account Policy (a descriptor with all xpubs and keys
removed), plus optional notes. (BTW, I think double sha256 or HMAC is
overkill).

Example: for the reference bit descriptor that might result in:

```
wsh(sortedmulti(2,xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/1/0/*,xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH/0/0/*))
```

What Blockchain Commons (and the Airgapped Wallet Community) call a policy
map would be

```
wsh(sortedmulti(1,,,))
```

A PBKDF of that as would be unique for all 2 of 3 segwig transactions. With
the addition of the addition of the Policy Map creators optional note, it
would be truly unique. The Policy Map and/or PBKDF are small and could
easily added to existing APIs.

So for legacy hardware, we can use existing 48' subtree, but 3' as the
format for this form (2' is segwit), then the desktop can just ask for the
/48'/0'/0'/3'/PBKDF' when it requests a new xpub from the hardware token.
More sophisticated Airgapped apps you can send
"wsh(sortedmulti(1,,,))"+label and let the cosigner app do the PBKDF, and
optionally allow it return something different in a full keyset (i.e.
"[90081696/48'/0'/0'/3'/af3948cg…'/]xpub6DYLEk…", and then the requesting
app, knowing that it is different from the PBKDF can know what to do if it
needs to what to ask for in the future.

The other advantage of this technique is that the cosigner app can know
what policy it is participating in, before the descriptor is completed. It
may decide it doesn't want to participate in some funky 4:9 with a weird
script, and not return an xpub at all.

Long term I think a commitment scheme should be used, so that you don't
reveal what xpub you offered until all the parties xpubs are shared, but as
Pieter said, we can do that at the same time we do the musig. But we need
to prevent xpub reuse NOW, and I think my proposal easy and could the job.

-- Christopher Allen, Blockchain Commons
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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']
xpub6DYLEkDfCdHzh5FHGHDJksQvFqu6kYANa1sfo6fA8n5ZWkSwyCRVVzyq9LY2eNGB6T9BKDeGJp2ZarjRZHd7WB95nSaFEDhFMK6zSV6D49b

We’ve also have been looking into multi round commitment scheme, but wanted
to align the UX so that it would work like to musig for users. Discussion
on it is scattered, for instance
https://github.com/BlockchainCommons/Airgapped-Wallet-Community/discussions/16#discussioncomment-212013

Nothing got as far as your version though.

So Concept ACK from Blockchain Commons. Less clear on your specifics
though. We will review.

Note that we are releasing a descriptor & multisig centric iOS and Android
reference wallet soon so solving this correctly and having interoperability
with others is very important for our roadmap.

— Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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 Commons, am very interested in
supporting discussion on this topic, and implementation of anything we
decide. I also have some Patron's to Blockchain Commons interested in this
topic and may be willing to financially support some reference code.

-- Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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 today. Part of the problem is
that bitcoin core itself didn't adopt these for a very long time after the
various wallet companies had them broadly deployed, so I don't believe that
these BIPs have quite the rigor that other BIPs have. Plus some entire
sub-topics are missing like a proposed BIP 48 that describes multisig paths
for hardware keys.

I encourage you to look back both on the PRs for those BIPs, and also
archives of this list. Unfortunately, I don't have a curated list of the
"best" of these — maybe a project for a future Blockchain Commons intern.

That being said, one particular focus in your question was on how to you
turn a master seed into the master key (m/0). Part of the conflict at the
time was a number of vendors wanted to avoid the 256 bits of entropy and
felt 128 bits were good enough.  A compromise was born of that, that even
today not all agree with. However, the proposed scheme was "good enough".

Today, I feel that how a master seed (entropy that has been turned into a
128 or 256 bit seed and that which is stored in hardware on a
ledger/trezor) is turned into the 512 byte master key for m/0 really needs
to be preserved, unless someone finds something cryptographically unsafe
about it. Why? Interoperability and avoiding vendor lock-in.

An example of this is the recent proposal from Satoshi Labs for SLIP-39. We
implemented it, but discovered that in practice the same seed restored
through BIP39 recovery would result in a different master key than SLIP39
recovery. This is because the Trezor team is one of the parties that were
unhappy with the compromise back in the BIP32 days, and thus they've
decided that as long as they are replacing BIP39 they would "fix" the
method of creation of the master seed.

Satoshi Labs has some rationale for these changes, but we (Blockchain
Commons and a small community of airgapped wallet developers), felt that
the interoperability and lock-in risks were too high. Once you used SLIP39
to create accounts, you must stick with SLIP39. This means you can only
restore seeds to wallets that support SLIP39, and most have chosen not to.

So we worked on instead a very closely related specification called SSKR
that also does Shamir, but uses the same seed->master key technique that
BIP32 does. This means that you can restore your SSRK shards back to a
seed, then move them to another device that only supports BIP39. This
prevents lock-in into a singular or small subset of wallet vendors. Our
current research spec is
https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-011-sskr.md
and reference code for sskr is at
https://github.com/BlockchainCommons/bc-seedtool-cli and we hope to offer
it as a BIP in future months. There is a small GitHub community discussing
this and other emerging airgapped and multisig standards at
https://github.com/BlockchainCommons/Airgapped-Wallet-Community/discussions

There is a similar problem with seed mnemonics Lightning Labs
implementations, which needed to offer metadata in addition to the seed.
This means their mnemonics are also incompatible and also have potential
lock-in and interoperability issues. You can't use their seeds with
C-Lightining. So we are puzzling through how to meet their needs for
metadata (and other parties in the multsig ecosystem were seed storage is
not enough and some metadata is needed), yet maximize round-trip
interoperability with multiple wallet vendors, and tools for conversion to
legacy formats like our seedtool.

So though at first glance your math seems correct and there are other,
potentially better ways to derive in a hierarchical fashion additional
keys, I'd be worried that it would suffer the interoperability and
potential lock-in that we are seeing with SLIP-39 and LND.

— Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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 Github over 100 watches, 300 forks, and 1200 stars, but we also know of
a number of people who learned how to program Bitcoin from the course and
have become full-time developers in our community or have joined your ranks
as bitcoin-core contributors.

We think that it's a unique course precisely because of its command-line
focus, which makes it "intermediate" between the introductory courses and
the more intense summer workshop and internships for bitcoin development.

In the course, we teach the fundamental RPC commands for interacting with
Bitcoin Core, primarily using the bitcoin-cli command line, but also with
later in the course curl and via other programming languages via RPC. By
doing so, we provide a nuts-and-bolts guide to the functionality of
Bitcoin that
really teaches how it works, and so will continue to be useful even if
readers choose to move on to higher levels of abstraction that hide some of
the Bitcoin fundamentals.

We're hoping that we can get your help in reviewing the core material
making up our newest iteration of this course:
https://github.com/BlockchainCommons/Learning-Bitcoin
-from-the-Command-Line/blob/master/README.md

The majority of the original work on Learning Bitcoin was done in 2017, and
despite some interim updates, by the start of this year, it had become
outdated due to the rapid state of Bitcoin development. We've been
expending effort in the last few months to update all of our existing
examples, to change out commands that have been deprecated or defaults
changed to ensure that the outputs that students see match what they'd get
from the command line.

In addition to updating the old course, we've also added major new sections
on descriptors

, Segwit
,
P2WPKH
,
and Segwit Scripting

and
whole new chapters on PSBTs

(including
HWI) and Tor
.
We think that what we have is some of the most accessible explanatory
matter available for these new topics at this intermediate level.

We'd love to get your comments on the whole front part of the course, from
Chapter 0 to 14. That's the complete, finished material on all of
`bitcoin-cli` and Bitcoin Scripting.

However, if you have limited time, the sections and chapters linked above
are the newest and rawest material in the course, and so those are the ones
that we'd like fact-checked the most. Either way, please feel free to
report out thoughts, comments, and corrections on the issues page

or
to enter PRs for specific corrections.

If you don't have time for that either, we are also looking for financial
support to continue this project. Blockchain Commons has already paid out
of pocket for this initial work, as open infrastructure to improve the
blockchain community, but we need to be able to complete this project,
which involves putting together chapters 15 and up on interacting with
Bitcoin RPC using more programming languages (C, C++, Python, Go, Rust
Swift), using LibWally, and onward to using Lightning. (We've got scattered
material for most of these sections right now, but they are very early
drafts and still need to be finished, standardized, and polished.)

You can also support Learning Bitcoin by becoming an ongoing patron for
Blockchain Commons through Github at
https://github.com/sponsors/BlockchainCommons, starting at $20 a month.
This will both help fund Learning Bitcoin and in the future will support
other projects intended to improve blockchain and cryptocurrency
infrastructure, such as #SmartCustody, Bitcoin Standup, LetheKit,
cryptographic libraries and more. A number of bitcoin-core contributors
already have their "badge" of support listed on our Sponsors' page, add
yours!

Alternatively, we can accept one-time Bitcoin contributions directly at our
BTCPay server: https://btcpay.blockchaincommons.com/

Thank you for your help!

Christopher Allen
Principale Architect & Executive Director
Blockchain Commons
_

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

[Christopher Allen via bitcoin-dev]

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 that step. Especially if I already run a
> full node.
>

There already is an emerging approach for this, called QuickConnect
https://github.com/BlockchainCommons/Bitcoin-Standup/blob/master/Docs/Quick-Connect-API.md

It is currently offered by BitcoinStandup (both Mac and Linux),
BTCPayServer, Nodl, MyNode, RaspiBlitz full node tools and hardware, and is
used currently by FullyNoded, FullyNoded2, and a couple of other
experimental apps to allow secure connection via Tor v3 from a remote to
your own personal full node.

We know that QuickConnect needs another major iteration and welcome
contributions to requirements and/or proposals for the next version.

We invite you to share your thoughts here.
https://github.com/BlockchainCommons/Bitcoin-Standup/issues/66

— Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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 little opinion as to whether this belongs in
> core or not, I think there are much more experienced folks who can weight
> in on that, but without something like this, you cannot limit your exposure
> for serving something like bip157 filters without removing your own ability
> to make use of some of those same services.
>

Our FullyNoded2 multisig wallet on iOS & Mac, communicates with your own
personal node over RPC, securing the connection using Tor over a hidden
onion service and two-way client authentication using a v3 Tor
Authentication key: https://github.com/BlockchainCommons/FullyNoded-2

It many ways the app (and its predecessor FullyNoded1) is an interface
between a personal full node and a user.

However, we do wish that the full RPC functionality was not exposed in
bitcoin-core. I’d love to see a cryptographic capability mechanism such
that the remote wallet could only m ask the node functions that it needs,
and allow escalation for other rarer services it needs with addition
authorization.

This capability mechanism feature set should go both ways, to a minimum
subset needed for being a watch-only transaction verification tool, all the
way to things RPC can’t do like deleting a wallet and changing bitcoin.conf
parameters and rebooting, without requiring full ssh access to the server
running the node.

If there are people interested in coordinating some proposals on how to
defining different sets of wallet functionality, Blockchain Commons would
be interested in hosting that collaboration. This could start as just being
a transparent shim between bitcoin-core & remote RPC, but later could
inform proposals for the future of the core wallet functionality as it gets
refactored.

— Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] PSBT in QR codes

[Christopher Allen via bitcoin-dev]

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 moving the discussion on this
topic to:

https://github.com/BlockchainCommons/AirgappedSigning/issues/4.

This is also the repository where I hope we can share examples, prototypes,
etc. until we have some consensus among these wallet developers for a
common QR code compatible format for PSBT to submit as an official BIP.

— Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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.

For instance with the offline tool #LetheKit
https://github.com/BlockchainCommons/bc-lethe-kit, you could go to your
vault, input your BIP39 from an offline titanium key or SLIP39 Shamir
shards, and then derive a child key in BIP39 form that can be delivered via
QR from the air-gapped LetheKit to another device you take away.

— Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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
http://bit.ly/SmartCustodyBookV101 and in github at
https://github.com/BlockchainCommons/smartcustodybook. It currently
requires a couple of hours and $200 or more of materials (home safe, 2
ledgers, titanium blanks, etc.) to safely product (significantly less time
and money than Glacier Protocol).

Presumably, people are not going to go to this level of protection for too
many keys, thus there needs to be methods to leverage the root seeds that
are properly protected.

Currently Blockchain Commons is working on standards for airgap solutions
for storing and signing from offline keys. Scenarios include using Shamir
and SLIP-39  on an offline device with no-WiFi or Bluetooth, an air-gapped
mobile phone in airplane mode, or another dedicated device (for instance
the SafeKey device if open source was an option). You would use this device
to create and restore seeds, convert seeds from BIP-39 to SLIP-39, derive
HD keys, and then use QR code from the device to transfer the generated
child keys for use by different apps. In some cases, this offline device
could also read QR transactions and sign them. We have working prototypes
of this today.

This technique works fine for online Bitcoin apps that accept child keys in
the form of xprv (or equivalents) such as those our FullyNoded2 iOS wallet
supports, but the problem for other wallets is that you can't go from an
xprv back to a seed — the xprv creation is a one-way hmac-sha512 operation
(still not convinced this was a good decision).

What I think Ethan is proposing is the ability to turn any child derived
xprv key into a new set valid seed words that could be used by a wallet or
other devices that don't understand xprv and will only allow import of new
seeds words. This gets even more complicated if the seed words are not the
standard BIP-39 set (which BTW, are not an ideal set of words, the
selection of the SLIP-39 words is much better).

Though possibly pragmatic, this approach would be a hack – starting with
some raw entropy, convert this to an entropy seed, then to words, then hmac
to xprv, then derive child keys, then convert that child key to a new
entropy seed, then hmac to xprv, and then derive child keys again, etc.

I'd really prefer to start with finding standards ways to protect the
entropy seed (not specifically the bip39 words derived from that but also
as derived roots for WebAuthN/FIDO, GPG, Signal/Session, etc.) that can be
then be used to create other hierarchies of keys using airgap solutions.

For instance, here is what FullyNoded 2 currently uses to restore a Bitcoin
wallet including root seed:

{
  "birthdate": 1584725088,
  "label": "Testnet Single Signature",
  "entropy": "b3b17e8f425bf7b96d68b67867cdc816",
  "walletName": "DEFAULT_EBaiuGgZQS_StandUp",
  "descriptor":
"wpkh([6955c2cb/84'/1'/0']tprv8giCxdrRRrKfQkXTJ4q2PNZBsPL7HiTXXteajiG8wqAGpLVsHJfN1EwwKM8F8x1Cuk8p6vh1KrKBCuZtZdDtL6Sc2CB1ou8sYiGSf6hcujv/0/*)",
  "blockheight": 1
}

Alternatively, FullyNoded 2 can also restore a wallets without the full
seed, so for instance, if this QR restore was missing the entropy field,
only derived child xprv from the descriptor could be used, so no other
accounts could be created but new addresses as children of the xprv could
be created.

The advantage of of an entropy seed storage centered technique is that I
can convert that entropy seed into either BIP39 words, or any number of
SLIP-39 shards, or Lightning words, and back. We are also looking at using
this with the VSS that underlies Schnorr Musig. We can talk other secure
tool makers on how to use this raw entropy for other purposes to create
chains or hierarchies of keys for their unique needs.

Blockchain Common's doesn't have a full architecture for this yet as we are
working on our POC and are seeking suggestions from other wallet vendors
(in particular lightning and non-bitcoin secure services) on requirements.
Let me know if you'd like to participate in the discussions (currently
either Github issues or a Signal group for the group)

— Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] v3 onion services

[Christopher Allen via bitcoin-dev]

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:
https://github.com/BlockchainCommons/Bitcoin-Standup#tor-v3-authentication-using-standup-and-fullynoded


Video demonstrating securing remote connection of a full node to the iOS
wallet Fully Noded: https://youtu.be/pSm2VftTCBI

More details on v3 authentication at:
https://github.com/AnarchoTechNYC/meta/wiki/Connecting-to-an-authenticated-Onion-service#connecting-to-authenticated-version-3-onion-services

— Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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 and
I really like 32 bytes. 33 seems so over the edge and so odd ;-)

Yes, there may be some prototype implementations out there that did some
extra work, and will need to be revised, but that is always the risk
developers take when writing code when the spec hasn't fully been
implemented yet.

If you do revise the spec, would you consider proposing a format for
sharing public keys in a non-binary form, maybe using bech32? Given some of
the protocols emerging that may use Schnorr public keys in novel ways,
having a single encoding format for them would be useful.

-- Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

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 feedback with regard to the
> high-level design of the new spec:
> https://github.com/satoshilabs/slips/blob/master/slip-0039.md
> Please focus your attention on the section entitled "Master secret
> derivation functions", which proposes several different solutions. Note
> that there is a Design Rationale section at the very end of the
> document, which should answer some of the questions you may have. The
> document is a work in progress and we are aware that some technical
> details have not been fully specified. These will be completed once the
> high level design has been settled.
>

I and a number of companies & communities I am involved with are very
interested in this.

A challenge is that Shamir Secret Sharing has subtleties. To quote Greg
Maxwell:

> I think Shamir Secret Sharing (and a number of other things, RNGs for
example), suffer from a property where they are just complex enough that
people are excited to implement them often for little good reason, and then
they are complex enough (or have few enough reasons to invest significant
time) they implement them poorly”.

Some questions for you:

* What other teams or communities besides Trezor are committed to
standardizing a Shamir Secret Sharing Scheme? I can say that the
#RebootingWebOfTrust community (meeting again for the 7th time next week in
Toronto https://rwot7.eventbrite.com) are very interested.

* Where do you want to hold discussions on this? Do people object to having
this discussion on this mailing list? Or should it be issues in SLIPS repo
or on some other mailing list?

* Presuming a successful split of secrets, I don’t know all the adversarial
problems that are associated with recovery of a SSS. As this would be an
interactive event, I presume an attacker can DOS a request to reassemble
keys (so maybe some the of integrity of each share vs all is required). And
of course there are the biggest problems:  impersonation of a reassembly
request and a MitM of a reassembly request. Are there other attacks? Are
you trying to mitigate any of these?

Two comments:

* The Lightning Network community has added to their BIP32 mnemonics the
ability to have a birthday in the seed, to make it easier  to scan the
blockchain for keys, as well as a byte with some way to know how to derive
keys paths for it. I don’t seee a BOLT for this (it was mentioned in
https://bitcoin.stackexchange.com/questions/74805/what-is-birthday-in-the-context-of-bip39-lightning-seed-generation)
 I would suggest that you also get some of their latest thoughts and
incorporate them.

* I worked with Chris Vickery while at Blockstrham on various possible ways
to improve mnemonic word lists. I’m not suggesting that you necessarily go
as far as we did to try to create a mnemonic that is iambic pentameter
poetry (inspired by
https://www.isi.edu/natural-language/mt/memorize-random-60.pdf), however,
we did find sources for words that are concrete (for example table is more
concrete than truth
http://crr.ugent.be/papers/Brysbaert_Warriner_Kuperman_BRM_Concreteness_ratings.pdf
) or have strong emotional valence attachment (truth is more emotional than
table), both of which make can words more memorable. I also found lists of
words that are hard to pronounce unless you are English native, and
eliminated them from my own list.

Among the results of this was a new BIP-39 2048 word compatible word list
filtered for memorability (concreteness & emotional valence) and
suitability for iambic pentameter, which is located:


https://github.com/ChristopherA/iambic-mnemonic/blob/master/word-lists/iambic-wordlist.json


…which was created from the repo at

https://github.com/ChristopherA/password_poem

You can a number of other word lists that I’ve collected here
https://github.com/ChristopherA/iambic-mnemonic/blob/master/word-lists/

If you want to replicate what we did with your own criteria, you may want
to incorporate information from the CMU dictitionary
http://www.speech.cs.cmu.edu/cgi-bin/cmudict, the top 5000 words
https://github.com/ChristopherA/password_poem/blob/master/top5000.json,
 concrete word lists
http://crr.ugent.be/papers/Concreteness_ratings_Brysbaert_et_al_BRM.txt and
emotional words  (valence) http://crr.ugent.be/archives/1003

— Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

[Christopher Allen via bitcoin-dev]

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

Possibly, but in the IPFS case I suspect the latency required to inspect
all hashes would likely  impact the ability of the miner to succeed in the
block. (True? I don’t touch mining software.)

Thus as long as all hashes look the same, and there are multiple content
addressable schemes that use hashes that have to be searched in order to
know to censor, you have to censor all or none.

— Christopher Allen

>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

[Christopher Allen via bitcoin-dev]

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 remove
the IPFS multihash prefix information to post a “bare” SHA256 hash to look
like many other hashes being posted in op_returns, to minimize any ability
for a miner to identify our transaction. The more projects that do this the
better — a form of herd immunity.

Longer term I’m looking for more responsible ways to publish this hash, for
instance have the hash be in the witness script data, so that it can be
easily purged from nodes that do not wish to preserve it and prevent block
size bloat. However, to do so everyone has to do it the same way, ideally
have it look like any other transaction. I’ve not quite seen a solid
proposal for best practices here.

— Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev