Rodolfo Novak [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2018-06-28 to 2020-04-06
💬 Posted a total of 3 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:23:47

- reply

📅 Original date posted:2020-04-06
📝 Original message:Hello,
We are planning on implementing the [Deterministic Entropy From BIP32 Keychains](https://gist.github.com/ethankosakovsky/268c52f018b94bea29a6e809381c05d6) BIP on Coldcard.
Is there a BIP number planned to be assigned and is there any review of this BIP yet?
Regards,
ℝ.
Rodolfo Novak || Coinkite Inc. || GPG: B444CDDA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200406/f1ab4174/attachment.sig>

2023-06-07 18:23:47

- reply

2023-06-07 18:14:08

- reply

📅 Original date posted:2018-08-19
📝 Original message:This is not a good solution. In UX colors have expected meaning. Red often means error, yellow cation, green possible, etc...
Text doesn’t have good legibility in colors, monochrome high contrast being the best.
You will also have issues with colorblind people.
Rodolfo
ℝ.
> On Aug 18, 2018, at 16:10, Martin Damgaard via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi bitcoin-dev at lists.linuxfoundation.org
> Here is my humble attempt to make a contribution to the impressive work that you all are doing.
> I am unfamiliar with the normal BIP procedures. I have therefore just tried to follow the example of BIP 176 by Jimmy Song, in order make something similar. I suggest a universal bitcoin value color scale, for tackling the same decimal problem, as identified by the BIP 176 proposal.
> I have attached the document in three different formats (*.rtf, *.pdf and *.docx) as I do not know your preferred format. I hope you will find my suggestion useful.
>
> Thank you and all the best
> Martin Damgaard
> <Universal bitcoin value color scale.rtf>
> <Universal bitcoin value color scale.pdf>
> <Universal bitcoin value color scale.docx>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180819/50ffe6d6/attachment.html>

2023-06-07 18:14:08

- reply

2023-06-07 18:13:17

- reply

📅 Original date posted:2018-06-28
📝 Original message:Hello Folks,
Thanks for expediting this debate, I understand some still disagree about how this final spec should look like.
1. Coldcard's plugin for Electrum using the original BIP spec is ready, https://github.com/spesmilo/electrum/pull/4470 <https://github.com/spesmilo/electrum/pull/4470>
2. Our hardware is ready with this spec (src will be public soon)
3. Samourai Wallet and Sentinel also are ready with the current spec.
We intend to upgrade it once the final spec is ready, but I need to ship Coldcard.
Cheers,
ℝ.
Rodolfo Novak || Founder, Coinkite || twitter @nvk || GPG: B444CDDA
> On Jun 27, 2018, at 13:55, Achow101 via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi,
>
> On June 26, 2018 11:09 PM, William Casarin <jb55 at jb55.com> 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.
>
> No, that is incorrect. That whole paragraph is actually outdated, it was intended
> for the possibility of adding output maps, which we have already done. I have
> removed it from the BIP.
>
> However, it is possible for a PSBT to contain very large unknown key-value pairs
> which could potentially cause a problem. But I do not think that large PSBTs should
> really be a problem as they are really something that the user has to enter rather
> than something received remotely without user interaction.
>
>
>
> On June 27, 2018 6:39 AM, Andrea via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>
>>
>> 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:
>>
>
> Parsers actually do know because that information is present in the unsigned transaction
> at the beginning of each PSBT. Since each input and output must be accounted for,
> a parser can just parse the unsigned transaction and from there it can know how
> many inputs and outputs to expect. If it sees more or less, it should throw an error
> as the transaction is invalid.
>
> Of course this implies that implementations will need to parse the unsigned transaction,
> but not all actually need to. Combiners do not need to, they just need to merge the
> maps together and follow the key uniqueness rule. They don't really need to know
> or care about the number of inputs and outputs, just that the PSBTs being merged
> share the same unsigned transaction and have the same number of maps.
>
> Other roles need to understand the unsigned transaction anyways, so they still need
> to parse it thus this isn't really a problem for those roles.
>
>>
>> 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.
>>
>
> I don't think such a limitation is practical or useful. A transaction can currently have, at most,
> ~24000 inputs and ~111000 outputs (+/- a few hundred) which is well beyond any useful limit.
> Additionally, such limits may not be as extensible for future work. It is hard to determine what
> is a reasonable limit on transaction size, and I don't think it is useful to have a limit. At worst
> we would simply create an invalid transaction if it were too large.
>
>
> Andrew
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180628/176ddd27/attachment.html>

2023-06-07 18:13:17

- reply