<unnamed>

Public Key

npub19g47w5ewcqlpd7n07wpkp5cvcu2gjwrse0vl47l0avwl9hu933xsqct5d0

Profile Code

nprofile1qqsz52l82vhvq0sklfhl8qmq6vxvw9yf8pcvhk06l0h7k80jm7zccngpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhg94flp0

Publishing to

relay.primal.net

Last Notes

2023-08-12 11:56:46 CEST

- 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 15:00:09 CEST

- 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-08 01:19:43 CEST

- 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-08 01:18:54 CEST

- 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-08 01:18:53 CEST

- 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-08 01:07:09 CEST

- 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-08 01:07:09 CEST

- 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-08 01:02:10 CEST

- 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-08 00:58:22 CEST

- 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-08 00:58:08 CEST

- 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-08 00:51:23 CEST

- 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 20:28:35 CEST

- 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 20:28:31 CEST

- 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 20:28:28 CEST

- 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 20:27:20 CEST

- 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 20:24:24 CEST

- 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 20:14:01 CEST

- 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 20:14:00 CEST

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