Christopher Allen [ARCHIVE]

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

Public Key

npub19g47w5ewcqlpd7n07wpkp5cvcu2gjwrse0vl47l0avwl9hu933xsqct5d0

Profile Code

nprofile1qqsz52l82vhvq0sklfhl8qmq6vxvw9yf8pcvhk06l0h7k80jm7zccng8km9p0

Author Public Key

npub19g47w5ewcqlpd7n07wpkp5cvcu2gjwrse0vl47l0avwl9hu933xsqct5d0

Show more details

Last Notes

2023-08-13 14:32:58

- reply

📅 Original date posted:2023-08-13
🗒️ Summary of this message: Concerns about payjoin implementations written in JavaScript and the need for a v2 upgrade to support receiving. Progress is being made with reference libraries in Typescript and plans to expand. Some wallets are using URs in JavaScript but no open source libraries have been announced yet.
📝 Original message:
On Sat, Aug 12, 2023 at 2:20 PM Dan Gould <d at ngould.dev> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230813/7138f6f7/attachment.html>

2023-08-12 09:56:46

- reply

📅 Original date posted:2023-08-11
🗒️ Summary of this message: The author suggests using base64url instead of base64 encoding for the psk in the URI, and recommends UR encoding for displaying via QR codes.
📝 Original message:
On Fri, Aug 11, 2023 at 3:29 PM symphonicbtc via bitcoin-dev <
bitcoin-dev at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230811/5be29a12/attachment.html>

2023-06-09 13:00:13

- reply

📅 Original date posted:2020-05-08
📝 Original message:
On Fri, May 8, 2020 at 2:00 PM Keagan McClelland via bitcoin-dev <
bitcoin-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200508/b2fc3d0f/attachment-0001.html>

2023-06-09 13:00:09

- reply

📅 Original date posted:2020-05-17
📝 Original message:
On Thu, May 14, 2020 at 8:30 AM Keagan McClelland via bitcoin-dev <
bitcoin-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200517/f483ba8b/attachment-0001.html>

2023-06-07 23:21:41

- reply

📅 Original date posted:2023-05-08
🗒️ Summary of this message: A proposal to reject witness scripts with arbitrary data between OP_FALSE and OP_IF flags to prevent overloading the network with inscriptions, while still allowing taproot benefits, has been suggested. However, there are other ways to inscribe data. Some have called for a larger OP_RETURN to store tagged root of a hash-tree, but objections to putting anything on-chain have delayed this. Inscriptions are causing problems for some free privacy services, and frustration is growing over the free-rider problem.
📝 Original message:On May 8, 2023 at 1:16:41 PM, Moth via bitcoin-dev <
bitcoin-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230508/be4a7f25/attachment-0001.html>

2023-06-07 23:19:43

- reply

📅 Original date posted:2023-02-19
🗒️ Summary of this message: Using only upper case letters and numbers in codex32 and avoiding most punctuation can significantly reduce the size of QR codes.
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230219/34d9d295/attachment.html>

2023-06-07 23:19:00

- reply

📅 Original date posted:2023-02-04
🗒️ Summary of this message: A proposed change to switch 80 to another number in Bitcoin's codebase is discussed, with the process of issuing a PR and addressing concerns outlined.
📝 Original message:On Sat, Feb 4, 2023 at 12:55 PM Aymeric Vitte <aymeric at peersm.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230204/00878238/attachment.html>

2023-06-07 23:18:59

- reply

📅 Original date posted:2023-02-04
🗒️ Summary of this message: Discussion on changing the OP_RETURN size in Bitcoin is ongoing, but ultimately requires code changes and community consensus for implementation.
📝 Original message:On Sat, Feb 4, 2023 at 9:01 AM Aymeric Vitte <aymeric at peersm.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230204/55d4fec8/attachment.html>

2023-06-07 23:18:58

- reply

📅 Original date posted:2023-02-03
🗒️ Summary of this message: Increasing the size of OP_RETURN to support a hash, signature, and metadata would be helpful in avoiding deviant scenarios, according to Christopher Allen.
📝 Original message:On Fri, Feb 3, 2023 at 3:52 AM Aymeric Vitte via bitcoin-dev <
bitcoin-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230203/b21fe300/attachment.html>

2023-06-07 23:18:54

- reply

📅 Original date posted:2023-02-01
🗒️ Summary of this message: Christopher Allen is exploring the tradeoffs of post-taproot Bitcoin and seeking the most pragmatic way to use the blockchain for non-transactional data.
📝 Original message: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 <pete at petertodd.org> wrote:
>
> >OP_FALSE
> >OP_IF
> >OP_PUSH my64bytes
> >OP_ENDIF
>
> What's wrong with OpPush <data> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230131/60e5928e/attachment.html>

2023-06-07 23:18:53

- reply

📅 Original date posted:2023-01-31
🗒️ Summary of this message: Which is better for placing 64 bytes into the Bitcoin blockchain: traditional OP_RETURN or spent taproot transaction? Debate on safety and uncensorability.
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230131/cac8f8b3/attachment.html>

2023-06-07 23:17:02

- reply

📅 Original date posted:2022-11-17
📝 Original message: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 team at 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
team at blockchaincommons.com or become a sponsor on GitHub
<https://github.com/sponsors/BlockchainCommons> and let us know it’s to
support Silicon Salon!
-- Christopher Allen, Principal Architect & Executive Director, Blockchain
Commons
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221117/e390ac79/attachment.html>

2023-06-07 23:13:14

- reply

📅 Original date posted:2022-08-29
📝 Original message:On Mon, Aug 29, 2022 at 9:12 AM Ali Sherief via bitcoin-dev <
bitcoin-dev at 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 <https://github.com/nochiel> on export
to a Plain-Text
Accounting <https://plaintextaccounting.org> friendly format,
initially the beancount
python app <https://github.com/beancount/beancount/>: (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.00000000 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220829/21fd9830/attachment.html>

2023-06-07 23:10:51

- reply

📅 Original date posted:2022-07-01
📝 Original message:On Fri, Jul 1, 2022 at 5:43 AM Alfred Hodler via bitcoin-dev <
bitcoin-dev at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220701/0acdb9a6/attachment.html>

2023-06-07 23:07:09

- reply

📅 Original date posted:2022-04-08
📝 Original message:On Fri, Apr 8, 2022 at 2:36 PM Erik Aronesty via bitcoin-dev <
bitcoin-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220408/ed177bd3/attachment.html>

2023-06-07 23:07:09

- reply

📅 Original date posted:2022-04-08
📝 Original message:On Fri, Apr 8, 2022 at 4:33 PM Christopher Allen <
ChristopherA at 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
<https://ntruprime.cr.yp.to/software.html>
>
— Christopher Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220408/d6013ace/attachment.html>

2023-06-07 23:02:10

- reply

📅 Original date posted:2022-01-11
📝 Original message:On Tue, Jan 11, 2022 at 5:02 PM René Pickhardt via bitcoin-dev <
bitcoin-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220111/6b0006d4/attachment.html>

2023-06-07 23:00:47

- reply

📅 Original date posted:2021-12-01
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211201/eb429a8d/attachment.html>

2023-06-07 22:58:23

- reply

📅 Original date posted:2021-08-31
📝 Original message:On Tue, Aug 31, 2021 at 12:18 PM Peter D. Gray <peter at coinkite.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210831/555ef40b/attachment.html>

2023-06-07 22:58:22

- reply

📅 Original date posted:2021-08-31
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210831/5b3915b1/attachment.html>

2023-06-07 22:58:17

- reply

📅 Original date posted:2021-08-25
📝 Original message:On Wed, Aug 25, 2021 at 12:42 PM Alekos Filini via bitcoin-dev <
bitcoin-dev at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210825/0715c389/attachment.html>

2023-06-07 22:58:08

- reply

📅 Original date posted:2021-08-19
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210819/54be28d3/attachment.html>

2023-06-07 22:57:44

- reply

📅 Original date posted:2021-08-05
📝 Original message:On Thu, Aug 5, 2021 at 8:07 AM Sjors Provoost via bitcoin-dev <
bitcoin-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210805/9bc986ff/attachment.html>

2023-06-07 22:55:46

- reply

📅 Original date posted:2021-06-29
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210629/72658551/attachment.html>

2023-06-07 22:53:22

- reply

📅 Original date posted:2021-05-13
📝 Original message:Over the last few years, Blockchain Commons
<https://www.BlockchainCommons.com/> has been working with our Airgapped
Wallet Community
<https://github.com/BlockchainCommons/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
<https://github.com/BlockchainCommons/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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210513/016fd47e/attachment.html>

2023-06-07 22:51:23

- reply

📅 Original date posted:2021-04-12
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210412/16421f4e/attachment.html>

2023-06-07 18:31:19

- reply

2023-06-07 18:28:35

- reply

📅 Original date posted:2021-02-11
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210211/30d4ab91/attachment.html>

2023-06-07 18:28:31

- reply

📅 Original date posted:2021-02-09
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210209/25fbca00/attachment-0001.html>

2023-06-07 18:28:28

- reply

📅 Original date posted:2021-02-05
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210205/859226ce/attachment.html>

2023-06-07 18:27:20

- reply

📅 Original date posted:2020-10-05
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201005/8d92b63e/attachment.html>

2023-06-07 18:26:03

- reply

📅 Original date posted:2020-07-22
📝 Original message:Dear Bitcoin Experts,
Learning Bitcoin from the Command Line
<https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/>
was one of Blockchain Common <https://www.BlockchainCommons.com>'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
<https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/03_5_Understanding_the_Descriptor.md>
, Segwit
<https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/04_6_Creating_a_Segwit_Transaction.md>,
P2WPKH
<https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/09_5_Scripting_a_P2WPKH.md>,
and Segwit Scripting
<https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/10_5_Scripting_a_Segwit_Script.md>
and
whole new chapters on PSBTs
<https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/07_0_Expanding_Bitcoin_Transactions_PSBTs.md>
(including
HWI) and Tor
<https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/14_0_Using_Tor.md>.
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
<https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/issues>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200722/a17a0187/attachment.html>

2023-06-07 18:24:24

- reply

📅 Original date posted:2020-05-08
📝 Original message:On Fri, May 8, 2020 at 2:00 PM Keagan McClelland via bitcoin-dev <
bitcoin-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200508/b2fc3d0f/attachment.html>

2023-06-07 18:24:21

- reply

📅 Original date posted:2020-05-17
📝 Original message:On Thu, May 14, 2020 at 8:30 AM Keagan McClelland via bitcoin-dev <
bitcoin-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200517/f483ba8b/attachment.html>

2023-06-07 18:24:09

- reply

📅 Original date posted:2020-04-27
📝 Original message:On Mon, Apr 27, 2020 at 1:44 PM Riccardo Casatta via bitcoin-dev <
bitcoin-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200427/aa2ad7f2/attachment.html>

2023-06-07 18:23:48

- reply

📅 Original date posted:2020-04-06
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200406/2956c78b/attachment.html>

2023-06-07 18:23:24

- reply

📅 Original date posted:2020-03-20
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200320/c56bcc9e/attachment.html>

2023-06-07 18:23:06

- reply

📅 Original date posted:2020-02-26
📝 Original message:On Wed, Feb 26, 2020 at 11:56 AM Jeremy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> As a replacement for paper, something like this makes sense v.s. what you
> do with a ledger presently.
>
> However, shamir's shares notoriously have the issue that the key does
> exist plaintext on a device at some point.
>
> Non-interactive multisig has the benefit of being able to sign
> transactions without having keys in the same room/place/device ever.
>
I agree that that interactive multisig is best for transactional recovery,
but there is still a place in our tool chest for Shamir split backups
especially in operational security scenarios, but as you state, you must be
aware of the limitations of Shamir, not only from the fact that there is
vulnerability in that you must restore keys in one place, but also there
are denial edge cases where when you only have k-1 of n, someone can deny
you knowledge of who gave you the corrupted share.
Right now the best C-library for Shamir sharding of recovery seeds is at
the Blockchain Commons Github
https://github.com/BlockchainCommons/sss/blob/master/README_slip39.md however,
this code base needs refactoring to be a good standalone library. This
requires us separating out the Shamir portions from the SLIP-39 mnemonic
elements and command-line elements. We also want to separate out the
randomness portions of the code so you can test different implementations
against deterministic randomness to ensure they give the same value (but
don't use this for production!) Once this is complete, we will be
submitting this library for formal review.
We are also working on air-gapped open-source open hardware for seed
creations and Shamir restoration. For instance, this device has no wifi,
Bluetooth, or persistent memory, and the serial port is disabled. It is
sized to fit in a bank safe deposit box. See
https://twitter.com/ChristopherA/status/1175465994644574208?s=20
[image: image.png]
Longer-term for seed sharding, we want to leverage the VSS (Verifiable
Secret Sharing) that future Bitcoin musig uses, which we believe has
advantages over Shamir Secret Sharing. It can be used for both traditional
sharding, but also for musig transactional recovery without restoring of
master seeds on a single device, and it is easier to prove that shares are
live and avoid denial use cases.
All this being said, we recommend Bitcoin multisig transactions as the best
solution for self-sovereign recovery of funds vs using Shamir (or SLIP39).
Lately, we've been working on PSBT and bitcoind descriptor support in our
alpha bitcoin wallet for iOS, FullyNoded 2
https://github.com/BlockchainCommons/FullyNoded-2 — in theory, this iOS
wallet can facilitate any scenario that bitcoind supports as a descriptor
as it communicates with your own private full-node over Tor v3.
P.S. If you've not seen it yet, our free #SmartCustody book
http://bit.ly/SmartCustodyBookV101 offers what we think are current best
practices for single seed recovery. We did not include multisig scenarios
in v1 of this book as at the time they were too difficult and error-prone
for most people. We are now working on v2 of the book which will cover
multisign and fiduciary scenarios now that PSBT is maturing and more
wallets are improving multisig support.
— Christopher Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200226/55bd31cd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 4330187 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200226/55bd31cd/attachment-0001.png>

2023-06-07 18:21:45

- reply

📅 Original date posted:2019-11-17
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191117/bcf562f0/attachment-0001.html>

2023-06-07 18:20:17

- reply

📅 Original date posted:2019-08-09
📝 Original message:On Fri, Aug 9, 2019 at 11:17 AM Pieter Wuille via bitcoin-dev <
bitcoin-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190809/663436d5/attachment.html>

2023-06-07 18:14:46

- reply

📅 Original date posted:2018-09-21
📝 Original message:On Fri, Sep 21, 2018 at 11:18 AM Andrew Kozlik via bitcoin-dev <
bitcoin-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180921/6018e9cd/attachment-0001.html>

2023-06-07 18:14:01

- reply

📅 Original date posted:2018-08-15
📝 Original message:On Wed, Aug 15, 2018 at 2:24 PM Jude Nelson via bitcoin-dev <
bitcoin-dev at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180815/de4d77d3/attachment.html>

2023-06-07 18:14:00

- reply

📅 Original date posted:2018-08-14
📝 Original message:On August 5, 2018 9:11:26 PM UTC, Lautaro Dragan via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180814/5c7a9e75/attachment.html>