Nostr notes by Peter D. Gray [ARCHIVE]

📅 Original date posted:2018-06-29 📝 Original message:... ...

2023-06-07T18:13:15Z

In reply to nevent1q…yakf
_________________________

📅 Original date posted:2018-06-29
📝 Original message:...
> I believe that this discussion has become bikeshedding and is really no longer constructive.
...

Thanks for saying this Andrew! I agree with your point of view, and personally I'm ready to lock this BIP down ... or at least move it to the next level of approval.

...
> I propose to move the BIP from Draft to Proposed status.

Yes please, all praise the BIP gods!

---
Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD 5A2A5B10

📅 Original date posted:2018-06-23 📝 Original message:On ...

2023-06-07T18:13:11Z

In reply to nevent1q…pzyr
_________________________

📅 Original date posted:2018-06-23
📝 Original message:On Fri, Jun 22, 2018 at 06:28:33PM -0400, Achow101 wrote:
> After reading the comments here about BIP 174, I would like to propose the following changes:
>
> - Moving redeemScripts, witnessScripts, and BIP 32 derivation paths to per-input and per-output data
...

I like this. I agree it's making things easier and it's more flexible.

> - Finalized scriptSig and scriptWitness fields
>
> To determine whether two PSBTs are the same, we can compare the unsigned transaction. To ensure that the
> unsigned transactions are the same for two PSBTs with data for the same tx, we cannot put scriptSigs or
> scriptWitnesses into it. Thus for each input, two new fields have been added to store the finalized scriptSig
> and finalized scriptWitness.
...

To be honest, I don't understand the reasons/implications of this change, but it seems harmless.

> - Mandatory sighash
...

Good improvement.

> - Encoding
>
> I have decided that PSBTs should either be in binary or encoded as a Base64 string. For the latter, several
> Bitcoin clients already support Base64 encoding of data (for signed messages) so this will not add any extra
> dependencies like Z85 would.
...

Personally, I don't think you should spec an encoding. It should be binary only and hex for developers and JSON interfaces. My thinking is that PSBT's are not user-visible things. They have a short lifetime and are nothing something that is "stored" or referenced much later. Hex is good enough and has no downsides as an excoding except for density.

On the other hand, suggesting a filename extension (probably .PSBT?) and a mime-type to match, are helpful since wallets and such will want to register with their operating systems to become handlers of those mimetypes. Really that's a lot more important for interoperability at this point, than an encoding.

> A draft of the revised BIP can be found here: https://github.com/achow101/bips/blob/bip174-rev/bip-0174.mediawiki
> If these changes are satisfactory, I will open a PR to the BIPs repo to update the BIP tomorrow. I will also
> create test vectors and update the implementation PR'ed to Core.
...

Looking forward to test vectors, and I might have more to say once my code can handle them (again).

Feedback on the BIP as it stands now:

- Appendix A needs an update, and I suggest defining symbols (PK_PARTIAL_SIG == 0x02) for the numeric key values. This helps implementers as we don't all define our own symbols and/or use numeric constants in our code.

- Those tables are just not working. Might want to reformat as descriptive lists, point form, or generally anything else... sorry.

> Andrew
> _______________________________________________

---
Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD 5A2A5B10
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180623/9c0b1846/attachment.sig>;

📅 Original date posted:2018-06-21 📝 Original message:On ...

2023-06-07T18:13:08Z

In reply to nevent1q…smec
_________________________

📅 Original date posted:2018-06-21
📝 Original message:On Thu, Jun 21, 2018 at 04:32:07PM +0200, Tomas Susanka wrote:
...
> First of all, let me thank you for all the hard work you and others have
> put into this.
>
> On 21.6.2018 02:39, Achow101 via bitcoin-dev wrote:
> > While I agree that the BIP itself should be revised to reflect these suggestions, I fear that it may be too late. I know of a few other developers who have implemented BIP 174 already but have not yet responded to this email.
>
> We do realize that this discussion should have happened earlier, however
> agreeing on a good standard should be the number one priority for all
> the parties involved.
>
> The fact that someone already implemented this is indeed unfortunate,
> but I don't think we should lower our demands on the standard just
> because of a bad timing.

We all want a "good" standard but we have that already, IMHO.

What you are really saying is you want a "better" standard, and I
would argue that's our enemy right now. It's just too easy to propose a
few tweaks, with "wouldn't it be better if..."

I feel strongly we are entering the "design by committee" territory with BIP174.

I have personally implemented this spec on an embedded micro, as
the signer and finalizer roles, and written multiple parsers for
it as well. There is nothing wrong with it, and it perfectly meets
my needs as a hardware wallet.

So, there is a good proposal already spec'ed and implemented by
multiple parties. Andrew has been very patiently shepherding the PR
for over six months already.

PSBT is something we need, and has been missing from the ecosystem
for a long time. Let's push this out and start talking about future
versions after we learn from this one.

---
Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD 5A2A5B10

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180621/8d63430a/attachment.sig>;

📅 Original date posted:2018-06-21 📝 Original message:On ...

2023-06-07T18:13:04Z

In reply to nevent1q…xu9c
_________________________

📅 Original date posted:2018-06-21
📝 Original message:On Tue, Jun 19, 2018 at 05:20:34PM +0200, Jonas Schnelli wrote:
...
>
> I don’t see any reasons why space would be an issue.
>
> HWWs probably can’t handle PBST natively since it is not optimised for
> presenting various informations in a signing-verification.

The Coldcard hardware wallet is PSBT native and does work directly from PSBT.

> A single stream-in of a PSBT through USB (or similar channel) will not work in
> many cases since HWW come often with very restrictive RAM constraints.

For the Coldcard, we expect a PSBT to be 'uploaded' over USB (can
also be provided on MicroSD card) and we work in-place with it,
scanning over it a few different times. If the user approves the
transaction, we produce a signed PSBT or final transaction and that
gets downloaded.

We support 256k byte PSBT files with hundreds of inputs/outputs
(IIRC, and exact limits still TBD) and are operating in a system
with only 25k free RAM after startup.

> Furthermore, I forget to mention in my last mail, that registering (or defining)
> a mime-type for PSBT would probably a great usability feature.
> (Send PSBT by email/messanger and with dbl-click to open feature, etc.)

+1 for mimetype, especially since it's a binary format.

---
Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD 5A2A5B10

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180621/be77e362/attachment.sig>;