| Age | Commit message (Collapse) | Author |
|---|
|
BIP 0174: Fix typo in PSBT_OUT_BIP32_DERIVATION
|
|
|
|
The descriptions for this field differ between bip370 and bip174. I suppose the correct format of PSBT_GLOBAL_TX_MODIFIABLE is the one in BIP370.
|
|
|
|
Add bip-0371.mediawiki, update readme, and update BIP 174 with
new field types.
|
|
PSBT_OUT_SCRIPT should be 0x04, not 0x03.
|
|
The description of keytype incorrectly said it had to be unique: it's the
whole key that must be unique, not the keytype (since we can for instance
have multiple xpubs in the global map).
|
|
BIP 174: Add test vectors for additional unsigned tx serialization
|
|
There are some edge cases with unsigned tx serialization, so this adds
test vectors for them. Specifically, an unsigned tx with witness
serialization is invalid, a transaction with 0 inputs and 0 outputs is
valid, and a transaction with 0 inputs and non-0 outputs is valid.
|
|
I, personally, find this easier to read.
|
|
Fixing Simple Signer Algorithm
|
|
|
|
Previously these tests were using 0x0f as the unknown field number. As
these have now been defined, change them to use 0xf0 instead as it is
unlikely we will use those anything soon.
|
|
Simple Signer Algorithm was lacking an index argument (last one) on all function calls
|
|
|
|
|
|
BIP 174: require creator to initialize empty output fields
|
|
This partially reverts c0991047e25a35d1ddf241f304a079e9893eed69.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"Variable length string identifier" is not defined anywhere, and the suggestion
to use "0x00" is also deeply unclear. I assumed it meant a nul-terminated
string!
Be explicit: you mean it must be a compact siz1\e unsigned int length, followed
by that many identifier bytes, followed by a compact size unsigned int subtype,
followed by optional keydata.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
|
|
|
|
|
|
BIP174: add `_IN_` to names of new hash preimage fields
|
|
BIp 174: fixing typo in rationale reference with closed tag
|
|
|
|
|
|
[Bitcoin Core uses "roles" instead of "responsibilities"](https://github.com/bitcoin/bitcoin/blob/master/src/psbt.h#L559) and it makes semantical sense (plus less verbose).
|
|
The current version of the spec requires creator role to initialize empty input fields, but says nothing about output field initialization. At the same time, the following role, updater, "should also add redeemScripts, witnessScripts, and BIP 32 derivation paths to the input and output data if it knows them.", which does not make any sense if the fields were uninitialized. The [current Bitcoin Core implementation does this](https://github.com/bitcoin/bitcoin/blob/a24806c25d7a81a9c436de58eb5778d93abab16b/src/psbt.cpp#L12), and [other PSBT implementations, like rust-bitcoin, follow this practice](https://github.com/rust-bitcoin/rust-bitcoin/blob/master/src/util/psbt/mod.rs#L59)
|
|
|
|
|
|
BIP 174: Fix formatting changes
|
|
BIP174: add hash preimage fields to inputs
|
|
|
|
|
|
|
|
|
|
BIP 174: Specify that separator only appears at end of the map
|
|
PSBT_INPUT_PROPRIETARY -> PSBT_IN_PROPRIETARY
PSBT_OUTPUT_PROPRIETARY -> PSBT_OUT_PROPRIETARY
to be consistent with other in/out type names that use shortened `IN` and `OUT`
|
|
BIP174: Fix wrong description about Proprietary Use Type
|
|
BIP174: remove 'first byte is the type' comment for key data
|
|
BIP-174: test data: fix value length
|
|
|
|
In the test case "Case: PSBT With invalid output witnessScript typed key", after PSBT_OUT_WITNESS_SCRIPT key with garbage data (which ends with `...478ef51309d`, follows value `2b` which would denote the length of the data value of the key. But the length of actual remaining data is only 7 bytes. Thus, an implementation that reads key-value pairs and checks for validity of the key data after it has read the current key-value pair, will not be able to hit the exact condition intended for this test case: extra data within the key itself. This is because such implementation will hit serialization error when it will try to read the data of the value and will get the short read.
Reading full key-value pair and then checking key format afterwards is fairly normal thing to do, as the format of the keys with all their meaning is an abstraction of higher level than just the simple key-value serialization format.
The proposed change is to replace byte `2b` after the key data to `06` and thus make the value length in the key-value pair valid (not going beyond the end of the data).
base64 encoding has been changed accordingly.
|
|
|
|
As the key type is now defined as compact size integer, `At the beginning of each key is a compact size unsigned integer representing the type`, the comment in the first table in the document, about first byte of the key being the key type is no longer accurate.
As the structure of the key data is described further in the text after the table, and the comment that it starts with the compact size integer seems a bit long to be in that table, I think it is better to just remove the comment about the key data structure from the table, and leave the explanation to the text after the table.
|
