Bitcoin in Berlin

Wallet standards, hardware implementations, heuristics—here’s what went down at the first annual S3ND meeting

Attendees at the first annual S3ND meeting.

Held on April 1–2 in Berlin, the first annual S3ND meeting began with a discussion on the generic hardware wallet standard. As discussions developed, problems with wallet software were highlighted — imagine a website requesting public keys from your wallet so you can sign a multi-signature transaction later . Higher level protocol would be developed around both cases.

For hardware implementation, it was understood that devices would probably have vendor-specific drivers for hardware, but implement the standard protocol.

The aim is to provide “detached” signing, where one entity requests a signature from another, whether the requestor is a bitcoin wallet requesting it from hardware, or a website making a request of a software wallet.

We also discussed other compatibility aspects of bitcoin wallets, such as

whether wallets should accept each others’ HD seeds. We reached a consensus that supporting full recovery by another wallet would be impossible, but that wallets MUST be able to recover their own funds.

Other interesting UX aspects were also highlighted. For example, because BIP39 seeds lack versioning or any labeling for their purpose, it was suggested that wallets strongly advise users to write down the name of the wallet that produced the seed, as another wallet importing it may mislead the user about their bitcoin balance.

On to wallet and transaction privacy. We discussed heuristics that can be used to fingerprint a specific wallet (allowing us to learn what produced a transaction or owns an address). There are already some projects with this in their scopes, although it was stated that some proposals affect the anonymity set of wallets that don’t implement the proposal, and should be discouraged.

In addition, it was mentioned how several wallets have adopted tricks for privacy as best practice, but there is no place to share them.

The Payment Protocol (BIP70) was also discussed — it was accepted as unfortunate that few merchants have implemented it on their websites, potentially because of the PKI aspect. It may also be that merchants prefer to use Bitpay for its currency conversion. It was also agreed that BIP70 could be modernized to allow RBF policies, fee rate requests, and more.

Segregated witness was discussed briefly, its new address proposal, and migration of wallets between compatible script types. Most indicated they were ready for its activation.

On a “common library” for bitcoin: libwally-core is being developed (in C)

to suit HSM’s & bindings to other languages. Also discussed was the wide

array of problems faced by libraries: not fully implementing BIPs, implementation errors, and issues after soft-fork activation. There was a general agreement that a repository containing a “complete” set of test cases would be useful for the implementation of cross-testing.

The event’s attendees were representative of the wider wallet ecosystem, with full nodes, hardware and software wallets, and lightning network developers contributing to discussions.

On the first evening we were treated to beer, as well as a demonstration of an onion-routed lightning network payment (over test-net!) Needless to say, the lighting network’s progress was discussed during the following day’s session, with an overview of recent and upcoming developments and software releases.

On day two, attendees agreed to focus on the following areas of immediate interest:

detached signing standard (for hardware and software) common library: libwally-core test vectors mission extensions to the payment protocol compile wallet tricks to wiki

BTC.com was pleased to be present and participating in the S3ND initiative,

and we look forward to collaborating again in the near future.

We also would like to thank Thomas Voegtlin for hosting the event, and everyone who attended for the fun!