PSBT support

[angrymouse]

Is there any plans to add support for PSBTs?

[cmdruid]

I currently do not have plans for it. PSBT is a convoluted and misguided specification. I am not opposed to adding PSBT parsing to the library if there is an existing library that I can use. However there isn't much to work with. Just reviewing the code for the top two libraries proves the point that PSBTs are convoluted:

https://www.npmjs.com/search?q=psbt

You do not need to serialize transactions before they hit the blockchain. I think people use PSBT because other people use it, without questioning why you really need it, versus simply using regular JSON.

If you can get away with it, I would stick to JSON and just add a few extra fields that you need for coordinating a multi-signature transaction. You can parse the SIGHASH flag from a signature and that will tell you most of what you need to know (in regards to whether inputs/outputs can be combined), and it's helpful to let people store a derivation path as well (so they can cross-check an address). That's pretty much it. You can borrow any other proposed field from the PSBT spec and just use it if you need it (or add your own), and you don't have to mess with a custom parser to do it.

JSON all the way.

[0xfinetuned]

@cmdruid Most browser wallets only support PSBTs tho. Is there a way to just give them hex ?

[cmdruid]

@cmdruid Most browser wallets only support PSBTs tho. Is there a way to just give them hex ?

Can you provide me with a few examples? I'll look them over and see if I can port over their PSBT encoding/decoding functionality.

[0xfinetuned]

I'd say to start with sats connect from Xverse and maybe offer more support from other wallets from there, like phantom and unisat

[wujiantao123]

What's going on? Any information or what should we do

Seek Assist

[cmdruid]

If you want to add a PSBT serializer / parser in a pull request, I would be happy to merge it.

You can use the @cmdcode/buff library to handle a lot of the heavy lifting.

A PSBT tool would have to implement BIP-174 for serialization and BIP-370 for the additional fields.

Other libraries that I have seen do not have an separate PSBT tool that I can merge. They are either borrowed from another library or heavily ingrained in their transaction serialization.

I'm willing to add PSBT support, but at the end of the day it's a custom serialization format for JSON data. There's nothing wrong with passing the same exact data as JSON. The serialization is completely unnecessary and is only used out of habit.

[blvrg]

Would it be possible to build something like https://github.com/orenyomtov/openordex with only JSON? 🤔

[BennyTheDev]

Hey, what else would you suggest to use instead? People use PSBTs for swapping assets.

I currently do not have plans for it. PSBT is a convoluted and misguided specification. I am not opposed to adding PSBT parsing to the library if there is an existing library that I can use. However there isn't much to work with. Just reviewing the code for the top two libraries proves the point that PSBTs are convoluted:

https://www.npmjs.com/search?q=psbt

You do not need to serialize transactions before they hit the blockchain. I think people use PSBT because other people use it, without questioning why you really need it, versus simply using regular JSON.

If you can get away with it, I would stick to JSON and just add a few extra fields that you need for coordinating a multi-signature transaction. You can parse the SIGHASH flag from a signature and that will tell you most of what you need to know (in regards to whether inputs/outputs can be combined), and it's helpful to let people store a derivation path as well (so they can cross-check an address). That's pretty much it. You can borrow any other proposed field from the PSBT spec and just use it if you need it (or add your own), and you don't have to mess with a custom parser to do it.

JSON all the way.

[cmdruid]

Hey, what else would you suggest to use instead? People use PSBTs for swapping assets.

In regards to the tx, version is 2 implied as standard, also locktime can be implied to be zero. Partners need to exchange inputs and outputs (use JSON), then exchange signatures.

You could collect inputs and outputs (JSON) in one round, create the tx (JSON), then pass around the tx to collect signatures (JSON) in a second round. Include meta fields (like txfee) if you need consensus on certain terms.

In contrast, the BIP174 PSBT spec is a state machine that handles the parsing and validation of a growing list of fixed custom types. You have to handle pass-thru of unknown types, plus special handling of addresses, derivation paths, and other things that may not be relevant to swapping ordinal assets.

There's also a three-way table that outlines for each custom field if it's cross-compatible, v1 only, or v2 only. And test vectors for handing a variety of combinations of key types, input types (both legacy and witness), output types, and sighash types.

JSON doesn't require you to perform any special handling of key/value pairs. You can safely ignore unknown keys. JSON parsing is included virtually everywhere. There's great validation libraries (like zod) that accept JSON as it is a universal format.

Maybe there are use cases where PSBT format makes more sense. If there is a standalone PSBT library that works I would be very happy to merge it. I haven't seen any PSBT code that looks portable though, otherwise I would offer to just tear it from another library and make a standalone tool.

[cmdruid]

Would it be possible to build something like https://github.com/orenyomtov/openordex with only JSON? 🤔

The whole ecosystem could be using JSON to swap assets, no reason to use a tired old format.

It's not like old wallets understand ordinal theory anyway so it would be a great opportunity to build something better.