Change Details

This implements [[ https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki | BIP70 ]], as well as an extension of the [[ https://github.com/badger-cash/slp-specifications/blob/master/slp-payment-protocol.md | SLP Payment Protocol ]]. This implementation maps a PaymentRequest to an `PaymentAction`, a data structure introduced in D17822 (as `Action`). By designing the wallet and BIP70 implementation simultaneously, we get nice harmonies that otherwise might result in inconsistencies. This way, the data structure that's emitted by the BIP70 library is the same that is consumed by ecash-wallet. Also, it allows us for this to become a standard in the eCash ecosystem. This diff adds `@bufbuild/protobuf` as external dependency to ecash-lib, which stops it from being dependency free. Here's why this might not be an issue: - The dependency itself has no dependencies - It's quite small (still, like +66kB non-minified for everything) - If it were to become an issue, we could simply include the needed methods, like done in [[ https://github.com/hansekontor/checkout-components/blob/6b3be5f50e1be82bdff461172ff08de8a4ef3a9b/lib/b70/utils/protoreader.js | b70 ]]. These are possible alternatives for this approach and why we might not want to opt for them: - Add a new module, e.g. ecash-payments: This is mostly reasonable, but makes it harder to use; a user has to add multiple dependencies, manage multiple versions etc., and it also makes it harder for us to develop and maintain. Also, we have less intra-module synergies, e.g. adding small helper methods like coin selection on top of PaymentAction over time. The upside would be that the bundle size might be smaller for people who don't want to use BIP70 (who are these heretics??); but, if this is the case we can make it tree-shakeable - Don't include `@bufbuild/protobuf` as dependency but instead make PaymentContext generic: This just adds complexity to both users and developers of the library, while only giving the minimal benefit of being potentially a smaller build. - Move it into ecash-wallet: This also makes sense, but having a good BIP70 implementation independent of a wallet implementation would be better. This way, devs can make their app "speak" BIP70 without also having to integrate a full wallet. In the future however we might want to move ecash-wallet into ecash-lib. The X509 part of this library is mostly inspired by [[ https://github.com/hansekontor/checkout-components/blob/main/lib/b70/x509.js | b70's X509 ]].

Bunch of changes that will have to be split out and testedThis implements [[ https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki | BIP70 ]], also probably will rename some stuff, but good to see alreadys well as an extension of the [[ https://github.com/badger-cash/slp-specifications/blob/master/slp-payment-protocol.md | SLP Payment Protocol ]]. Currently doesn't even compileThis implementation maps a PaymentRequest to an `PaymentAction`, a data structure introduced in D17822 (as `Action`). By designing the wallet and BIP70 implementation simultaneously, we get nice harmonies that otherwise might result in inconsistencies. This way, the data structure that's emitted by the BIP70 library is the same that is consumed by ecash-wallet. Also, it allows us for this to become a standard in the eCash ecosystem. This diff adds `@bufbuild/protobuf` as external dependency to ecash-lib, which stops it from being dependency free. Here's why this might not be an issue: - The dependency itself has no dependencies - It's quite small (still, like +66kB non-minified for everything) - If it were to become an issue, we could simply include the needed methods, like done in [[ https://github.com/hansekontor/checkout-components/blob/6b3be5f50e1be82bdff461172ff08de8a4ef3a9b/lib/b70/utils/protoreader.js | b70 ]]. These are possible alternatives for this approach and why we might not want to opt for them: - Add a new module, e.g. ecash-payments: This is mostly reasonable, but makes it harder to use; a user has to add multiple dependencies, manage multiple versions etc., and it also makes it harder for us to develop and maintain. Also, we have less intra-module synergies, e.g. adding small helper methods like coin selection on top of PaymentAction over time. The upside would be that the bundle size might be smaller for people who don't want to use BIP70 (who are these heretics??); but, if this is the case we can make it tree-shakeable - Don't include `@bufbuild/protobuf` as dependency but instead make PaymentContext generic: This just adds complexity to both users and developers of the library, while only giving the minimal benefit of being potentially a smaller build. - Move it into ecash-wallet: This also makes sense, but having a good BIP70 implementation independent of a wallet implementation would be better. This way, devs can make their app "speak" BIP70 without also having to integrate a full wallet. In the future however we might want to move ecash-wallet into ecash-lib. The X509 part of this library is mostly inspired by [[ https://github.com/hansekontor/checkout-components/blob/main/lib/b70/x509.js | b70's X509 ]].