Nostr notes by Andrea [ARCHIVE]

📅 Original date posted:2021-03-17 📝 Original message:Thanks ...

2023-06-07T18:30:58Z

In reply to nevent1q…r3ul
_________________________

📅 Original date posted:2021-03-17
📝 Original message:Thanks for your time Andrew and ZmnSCPxj,

Jonas contrib was also referenced in twitter post provided by Andrew,
but the repetion is an effective underlining of its importance :)

I'm busy-at-work for a couple of days, but I'm planning my weekend spare
time to deal with infos from both of you... I guess I'll have further
questions :)

Il 17/03/21 05:24, ZmnSCPxj ha scritto:
> Good morning Andrew and Andrea,
>
> Further afield: https://en.bitcoin.it/wiki/Taproot_Uses
>
> Taproot ring signatures was also asked by Andrea, above page contains this link (have not actually read it myself): https://github.com/jonasnick/taproot-ringsig
>
> Regards,
> ZmnSCPxj
>

📅 Original date posted:2021-03-16 📝 Original message:Il ...

2023-06-07T18:30:56Z

In reply to nevent1q…xtle
_________________________

📅 Original date posted:2021-03-16
📝 Original message:Il 16/03/21 00:12, Andrew Poelstra via bitcoin-dev ha scritto:

> Having exposed keys also lets you do ring signatures over outputs, creating the
> ability to do private proof of funds via Provisions.
>

Hi! Sorry for the OT, could you provide some references to ring
signatures over/for/via taproot (I mean the schema or something like
that)? And what is "Provisions" (the capital letter makes me think it's
a product/technology)?
I'm a rookie following this mailing since just a few months...

📅 Original date posted:2018-06-27 📝 Original message:Hi ...

2023-06-07T18:13:16Z

In reply to nevent1q…4hkc
_________________________

📅 Original date posted:2018-06-27
📝 Original message:Hi William, Andrew, list,

As noted by William there are some types missing in the global-types definition, because the number of each map for I/O must be known to the parser in order to use the correct definitions for the types. At the moment a parser reading a key-value record does not know whether it should read it as per-input type or per-output, a way to address this is to declare in advance the number of maps and ensure they are ordered (inputs first). If you haven't already worked out some types for that i propose using:

Number of inputs
- key (None, only the type): PSBT_GLOBAL_INPUT_NUMBER = 0x01
- value: Varint

Number of outputs
- key (none, only the type): PSBT_GLOBAL_OUTPUT_NUMBER = 0x02
- value: Varint

On another note I think we can set a hard limit on the size of the PSBT, currently is 'legal' to produce a very large PSBT with an excessive number of Inputs and Outputs. By excessive I mean that even in the best case scenario (using the smallest possible scriptPubKey as in P2WPKH) it is possible to create a PSBT that would certainly create an invalid transaction (because of its size) when finalized. I haven't found anything related to this in the previous discussions, please ignore this if it was already proposed/discussed.

Cheers, Andrea.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On June 27, 2018 8:09 AM, William Casarin via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

>
>
> Hey Andrew,
>
> If I'm reading the spec right: the way it is designed right now, you
>
> could create hundreds of thousands of zero bytes in the input or output
>
> key-value arrays. As far as I can tell this would be considered valid,
>
> as it is simply a large array of empty dictionaries. Is this right? I'm
>
> worried about buffer overflows in cases where someone sends a large blob
>
> of zeros to an unsuspecting implementation.
>
> Also, the extensibility section reads:
>
> > Additional key-value maps with different types for the key-value pairs
> >
> > can be added on to the end of the format.
>
> "different types for the key-value pairs", is this referring to new
>
> types beyond the current global, input and output types?
>
> > The number of each map that follows must be specified in the globals
> >
> > section
>
> Is this out of date? Since there is only one type in the global section
>
> now (tx).
>
> > so that parsers will know when to use different definitions of the
> >
> > data types
>
> I'm not sure what this means.
>
> Thanks!
>
> Will
>
>
> ------------------------------------------------
>
> https://jb55.com
>
> bitcoin-dev mailing list
>
> bitcoin-dev at lists.linuxfoundation.org
>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2018-06-24 📝 Original message:Hi, I ...

2023-06-07T18:13:10Z

In reply to nevent1q…s0sk
_________________________

📅 Original date posted:2018-06-24
📝 Original message:Hi,

I think in the revised spec we can remove completely the "global types" as a map or even as typed record. Since there is only one type (the transaction) and it's compulsory to have one (and only one) we could just drop the definition of global type and the key associated with it, simply after the header + separator there must be a transaction. Having read all the discussion i also agree having per-input key derivation and per-output data is a lot more handy for signers, no special feeling regarding the encoding.Looking forward for the test vectors and the new spec.

Cheers, Andrea.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On June 23, 2018 10:33 PM, Andrew Chow via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

>
>
> On 06/23/2018 10:00 AM, William Casarin wrote:
>
> > Since we're still considering the encoding, I wonder if it would be a
> >
> > good idea to have a human-readible part like lightning invoices[1]?
>
> I don't think that is necessary.
>
> > Then perhaps you could drop the magic code as well?
>
> The magic is still necessary for the binary format in order to prevent
>
> normal transaction deserializers from accidentally deserializing a psbt.
>
> > Also we could do a base encoding that excludes + and / characters, such
> >
> > as base62 (gmp-style). It's easier to copy/paste (double clicking a
> >
> > string stops at / or + in base64 encodings).
>
> While that would be ideal, I think it is better to use an encoding that
>
> most wallets already support. Most wallets already have Base64 decoding
>
> available so that they can decode signed messages which also use Base64
>
> encoding. I think it is unnecessary to introduce another encoding.
>
> On 06/23/2018 11:27 AM, Peter D. Gray wrote:
>
> > 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.
>
> I think what will end up happening though is that, at least in the
>
> beginning, PSBTs will primarily be strings that people end up copy and
>
> pasting. Since a PSBT can get pretty large, the strings are rather
>
> cumbersome to move around, especially as hex. At least with Base64 the
>
> strings will be smaller.
>
> > 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.
>
> Agreed. I will include those in the BIP.
>
> > 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.
>
> Okay.
>
> > - Those tables are just not working. Might want to reformat as descriptive lists, point form, or generally anything else... sorry.
>
> I will try my best to fix that. Mediawiki sucks...
>
> Andrew
>
> bitcoin-dev mailing list
>
> bitcoin-dev at lists.linuxfoundation.org
>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev