Bitcoin full node and query server

May 28, 2018

View in context in the libbitcoin Slack #general mirror.

A
Alex01:27
Hello everyone! The team at SBI BITS has mentioned to @evoskuil that we would like libbitcoin to support threshold signatures. If you are curious what this is, a good starting place is https://www.cs.princeton.edu/~stevenag/threshold_sigs.pdf. There are, however, several implementations of threshold signatures with different characteristics (threshold-optimal, computational speed) so from a high-level view, we feel flexible support from libbitcoin is best. We have considered "external" and "internal" support. From bx, the external support adds a function bx input-prepare [-ah] [--config VALUE] [--index VALUE] [--sign_type VALUE] CONTRACT [TRANSACTION] whose arguments match that of bx input-sign. The argument EC_PRIVATE_KEY is omitted, however, as threshold signatures cannot provide the private key. The outputs of this call are the hex-encoded sighash as calculated at https://github.com/libbitcoin/libbitcoin/blob/master/src/chain/script.cpp:867 and the hex-encoded sighash_type from line 876. The user then generates the EC signature using his implementation of threshold signatures and the sighash, appends the sighash_type, and hex-encodes this result to be used in a subsequent call to bx input-set. Pros: maximum flexibility in threshold signature algorithm implementation; not specific to threshold signatures -- allows future signature algorithms to be used as well. Cons: signature implementation not necessarily vetted by libbitcoin. From bx, the internal support adds a function bx input-sign-partial [-ah] [--config VALUE] [--index VALUE] [--sign_type VALUE] EC_PRIVATE_KEY_SHARE KEY_SHARE_TYPE INTERMEDIATES_PRIV INTERMEDIATES_PUB CONTRACT [TRANSACTION] whose arguments mostly match that of bx input-sign. The argument EC_PRIVATE_KEY becomes EC_PRIVATE_KEY_SHARE as threshold signatures cannot provide the private key. To deal with the different implementations of threshold signatures, KEY_SHARE_TYPE is taken to select the cryptographic algorithm used. INTERMEDIATES_PRIV and INTERMEDIATES_PUB are hex-encoded serialized data structures that are specific to the cryptographic algorithm. On the first call to this function, INTERMEDIATES_PRIV and INTERMEDIATES_PUB are null so "" would have to be passed on the command line if they are positional arguments. Alternatively, they could be optional arguments. As existing threshold signature algorithms cannot be completed in one round (each user must provide his key share multiple times), the outputs of this call are the INTERMEDIATES_PRIV to be retained by the caller for his next call to this function and the INTERMEDIATES_PUB to be given to the next key share holder for his call to this function. Once enough key shares have been provided, then the output INTERMEDIATES_PRIV is null and the output INTERMEDIATES_PUB is the completed endorsement. The completed endorsement is used in a subsequent call to bx input-set. Pros: signature implementations vetted by libbitcoin. Cons: limited to the signature implementations provided by libbitcoin.