Kabuto Samourai [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-09-05 to 2017-09-07
💬 Posted a total of 5 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:05:32

- reply

📅 Original date posted:2017-09-07
📝 Original message:OutputType byte solution is nearly equivalent to {x,y,z} and adds redundant
data. Implementations could erroneously (maliciously) assign the wrong
output type for the given purpose field.
We could reduce the scope of this improvement to BIP43, as suggested by
Thomas. BIP32-generic wallets may implement something else.
On Thu, Sep 7, 2017 at 11:23 AM, Pavol Rusnak via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 07/09/17 06:29, Thomas Voegtlin via bitcoin-dev wrote:
> > A solution is still needed to wallets who do not wish to use BIP43
>
> What if we added another byte field OutputType for wallets that do not
> follow BIP43?
>
> 0x00 - P2PKH output type
> 0x01 - P2WPKH-in-P2SH output type
> 0x02 - native Segwit output type
>
> Would that work for you?
>
> The question is whether this field should be present only if depth==0x00
> or at all times. What is your suggestion, Thomas?
>
> --
> Best Regards / S pozdravom,
>
> Pavol "stick" Rusnak
> CTO, SatoshiLabs
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
-Kabuto
PGP Fingerprint: 1A83 4A96 EDE7 E286 2C5A B065 320F B934 A79B 6A99
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170907/e1d48d43/attachment-0001.html>

2023-06-07 18:05:31

- reply

📅 Original date posted:2017-09-07
📝 Original message:> Birthday
Why not make this block height, rather than a timestamp?
On Thu, Sep 7, 2017 at 11:25 AM, Pavol Rusnak <stick at satoshilabs.com> wrote:
> On 07/09/17 05:52, Kabuto Samourai wrote:
> > The birthday field is interesting. Could you provide some motivation for
> > its inclusion?
>
> Birthday is something SPV wallet developers have been wanting for years.
> It helps them with the initial scan, so SPV wallet does not have to
> download every block in the blockchain, but only the ones after birthday.
>
> > Could you also add some test vectors?
>
> I will add some test vectors, when we agree this is the way to go.
>
> > There are a few minor grammar / spelling errors, but we can nitpick
> > those after this goes to the pull request stage on bitcoin/bips.
>
> +1
>
> --
> Best Regards / S pozdravom,
>
> Pavol "stick" Rusnak
> CTO, SatoshiLabs
>
--
-Kabuto
PGP Fingerprint: 1A83 4A96 EDE7 E286 2C5A B065 320F B934 A79B 6A99
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170907/ac71a65b/attachment-0001.html>

2023-06-07 18:05:30

- reply

📅 Original date posted:2017-09-07
📝 Original message:Thanks for the proposal. Aside from potential privacy implications of
revealing the derivation path for non BIP-44, 45, 49 HD nodes, this scheme
is superior to the alternate {x,y,z}pub idea. Since coin_type is part of
the path, the 'xpub' prefix may be shared across all coins if they so
choose. This format provides lock-in for BIP-49 going forward and opens the
door for a parallel native-SegWit BIP.
The birthday field is interesting. Could you provide some motivation for
its inclusion?
Could you also add some test vectors?
There are a few minor grammar / spelling errors, but we can nitpick those
after this goes to the pull request stage on bitcoin/bips.
On Wed, Sep 6, 2017 at 5:29 PM, Pavol Rusnak via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The discussion about changing bip32 version bytes for SegWit got me
> thinking and I ended up with what I think is the best proposal:
>
> https://github.com/satoshilabs/slips/blob/master/slip-0032.md
>
> (It is hosted in SL repo for now, but if there is will, I would love to
> have this added to BIP repo as an extension to BIP32)
>
> Feel free to comment.
>
> --
> Best Regards / S pozdravom,
>
> Pavol "stick" Rusnak
> CTO, SatoshiLabs
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-Kabuto
PGP Fingerprint: 1A83 4A96 EDE7 E286 2C5A B065 320F B934 A79B 6A99
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170906/de229129/attachment.html>

2023-06-07 18:05:23

- reply

📅 Original date posted:2017-09-06
📝 Original message:> In addition, consensus might be more difficult to reach on that
Let's move forward with the simplest solution that solves the problem and
achieves consensus! Version bytes {x,y,z} fits the bill.
On Wed, Sep 6, 2017 at 4:26 AM, Thomas Voegtlin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> On 05.09.2017 21:00, Kabuto Samourai wrote:
> >
> > The Electrum approach is nice but may not go far enough, as xpub and zpub
> > both list "P2PKH or P2SH." Why not expand the number of version prefixes
> to
> > eliminate the ambiguity?
> >
>
> I agree that this would make sense if we had done it from the start.
> However, fixing that now might be difficult.
>
> My "xyz" proposal extends the current format in a way that is very easy
> to deploy, because existing software will require minimal changes.
> However, if we eliminate the p2sh ambiguity now, wallets will need to
> add extra safeguards, in order to prevent scenarios that are currently
> allowed, and they will need to handle legacy xpub/xprv differently than
> ypub and zpub. This would take much more time to deploy.
>
> In addition, consensus might be more difficult to reach on that; I guess
> not all developers will not agree that removing that ambiguity is
> useful. Since there is an infinity of possible P2SH scripts, it will
> never be possible to remove ambiguity from a master key associated to a
> P2SH script. Thus, the benefit of separating P2SH from P2PKH is not as
> strong.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
-Kabuto
PGP Fingerprint: 1A83 4A96 EDE7 E286 2C5A B065 320F B934 A79B 6A99
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170906/57f3bc91/attachment.html>

2023-06-07 18:05:22

- reply

📅 Original date posted:2017-09-05
📝 Original message:We support a change to the version bits of the HD serialization that will
inform the receiving utility of the exact derivation method used for the
pubkeys. Third-parties handling xpubs must not require additional
information from the user about the derivation path or serialization format
of the addresses under that xpub. When you have to ask, "Is this a SegWit
xpub?" then you've already lost.
Avoiding a total UX nightmare is in everyone's interests.
I think Luke and Thomas may be talking past one another. When exporting a
root master HD seed, encoding the {x,y,z}{pub,prv} distinctions makes no
sense, as the root seed should derive all paths for all coins. Wallets may
need additional code to discover which paths have been used when importing
a root seed. But when exporting / importing an account-level seed for
watch-only and receive address generation, changing the serialization
version bytes is appropriate and (in our view) essential to avoid loss of
funds.
The Electrum approach is nice but may not go far enough, as xpub and zpub
both list "P2PKH or P2SH." Why not expand the number of version prefixes to
eliminate the ambiguity?
On Tue, Sep 5, 2017 at 1:09 PM, Thomas Voegtlin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> On 05.09.2017 19:03, Luke Dashjr wrote:
>
> > It seems desirable to use the same seed for all different script
> formats...
>
> That does not seem desirable to everybody.
>
> If you want to guarantee that users will be able to recover all their
> funds from their mnemonic seed (and that is what they expect), then
> wallets must implement all script formats, even the ones that are
> deprecated. In addition, the list of script formats that must be
> supported is not defined in advance, but it keeps growing. This makes
> wallet implementation increasingly difficult. In the long run, seed
> portability is guaranteed to fail in such a system.
>
> > As you note, xpub\xprv are already being used for both P2PKH and P2SH. It
> > really doesn't make sense to differentiate segwit specifically.
>
> That's not a reason. The fact that xpub/xprv can be used for both P2PKH
> and P2SH has already resulted in users receiving coins on addresses they
> do not control.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
-Kabuto
PGP Fingerprint: 1A83 4A96 EDE7 E286 2C5A B065 320F B934 A79B 6A99
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170905/2725c4f2/attachment.html>