Author: Pieter Wuille 2018-06-21 17:39:57
Published on: 2018-06-21T17:39:57+00:00
The conversation is centered around the process of signing Bitcoin transactions using a Signer. The naive Signer can pre-serialize the transaction, fill out scriptPubKey from the provided unspent transaction output (UTXO), and move on to the next input. However, a less naive Signer will want to check things and possibly derive a scriptSig itself and check if it matches the given hash. Combiners and Finalizers also play a role in the Bitcoin transaction process.In a Bitcoin development email thread, the discussion focused on whether UTXOs are added by the Creator or an index server. It was noted that most of the information in derivation paths is opaque to the Creator, and a fixed structure is beneficial for compatibility between multiple signer implementations. Different encoding methods for JSON strings were also discussed, and the potential simplification of signers if redeem scripts and witness scripts were per-output instead of per-input. There was debate over the need for data per-output and it was concluded that it isn't worth including any other than what the original transaction contains. However, output scripts were deemed necessary so signers could know which outputs transferred funds and which didn't. Based on the previous points, the preference is to have everything per-input and per-output except the transaction itself. Finally, the discussion compared the typed record model and key-value models, and both were seen as equally complex.The conversation also touches on the role of sharing derivation paths and public keys with the Creator, as well as the possibility of delegating this task to sub-Creators.
Updated on: 2023-05-20T17:03:59.146798+00:00