In the integration of BIP-38 into libbitcoin we ran into two issues. First, the scenario that justifies the "confirmation code" is flawed. We have implemented full support for this, but have also marked it as deprecated.
I am seeking counter arguments, in case there is some scenario that we haven't imagined where it might be useful. Details here: [TLDR: the confirmation code cannot prove anything about the owner's ability to spend from the public-key/address that it confirms.] https://github.com/libbitcoin/libbitcoin/wiki/BIP38-Security-Considerations Second, BIP-38 envisions altchain integration but doesn't specify it. We have implemented the capability, documented here: [TLDR: incorporate the payment address version into the last byte of the encoded encrypted key prefixes, with backward compatibility] https://github.com/libbitcoin/libbitcoin/wiki/Altchain-Encrypted-Private-Keys If there is sufficient support I'll write up a Proposal that modifies BIP-38. Thanks to Neill Miller for the libbitcoin and bx BIP-38 pull requests. e
signature.asc
Description: OpenPGP digital signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
