Distributed PSBT construction

[nothingmuch]

rough draft of a BIP discussing when and how PSBTs merging is a join semi-lattice

this is the basis of state machines of the honest (#4), semi honest and BFT variants of multiparty transaction construction, and ensures these protocols do not depend on all peers observing a consistent ordering of protocol messages which simplifies coordination

TODO:

• various TODO comments
• diagrams, examples
• discuss how bip 370 state machine precedes to the bip 174 state machine, and similarly this precedes bip 370 state machine (states closer to the terminal state can be represented with lower PSBT versions)
• discuss tradeoffs of of PSBT_GLOBAL_TX_UNORDERED as an indicator that the order is random vs. PSBT_GLOBAL_UNORDERED_{INPUT,OUTPUT} with keydata and the input map serialized in the value
  • pro PSBT_GLOBAL_TX_UNORDERED marker and backwards compatible input/output maps:
    • unordered marker matches joinpsbts behavior
    • unique identification semantics are closer to BIP 370
    • only one logical place for authoritative input or output data
  • cons:
    • combine "just works" for unordered fields in this representation if done recursively, even with BIP 370/174 rules for legacy combiners, exploiting the fact that unique id under the old rules is meaningless
    • ambiguous if both positional and keyed input/output data is included, possible safety issue if conflicting due to unintentional forwards compatibility for older implementations

[nothingmuch]

PSBT_GLOBAL_TX_UNORDERED is modeled as a bitfield based on BIP 370's MODIFIABLE field, but it's not clear that that is useful, and it complicates implementation.

I think it's sufficient to define PSBT_FLOBAL_TX_UNORDERED as just a bool since i can't think of any situation where simply marking the unordered inputs as non-modifiable isn't sufficient.

it could still be encoded as a bitfield where both bits 0 and 1 have to be set, for forward compatibility, allowing some refinement in the future if a use case arises that requires fixing the order of the inputs or the outputs (so potentially all combinations of { inputs, outputs} x { modifiable, ordered } might be representable but only some make sense to implement (unordered seems to only make sense while at least inputs or outputs are modifiable).

note that this is specific to more than two parties, in the two party setting SIGHASH_SINGLE or some other reason can impose specific ordering requirements, but BIP 370 Constructor is already appropriate for such use cases.

in a multiparty atomic swap/net-settlement transaction involving something like ordinals, my understanding is they are typically managed using dust UTXOs. this can be managed in a hybrid setup: use BIP 370 for those coins in one PSBT, concurrent constructor for the exchange part, and then fix the order of that and concatenate the two transactions with the existing joinpsbts functionality. there is no benefit to privacy from shuffling the ordinals with the fungible bitcoin so long as their containing UTXOs are more or less a fixed amount of dust.

i'm still of the opinion that ordinals are basically an anti fungibility psyop and a zero sum game with externalities, so i don't want to take part in encouraging that, because this can be easily composed i think that's a solid argument for why that should be out of scope and not mentioned in the doc at all