On 07.09.2017 18:23, Pavol Rusnak 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
> 0x
On 07/09/17 21:35, Andreas Schildbach via bitcoin-dev wrote:
> In case of Bitcoin Wallet, the depth is not null (m/0'/[0,1]) and still
> we need this field.
But the depth of exported public key will be null. It does not make
sense to export xpub for m or m/0' for your particular case.
> I think i
On 09/07/2017 06:23 PM, Pavol Rusnak via bitcoin-dev 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
On 07/09/17 18:47, Jonas Schnelli wrote:
> But not sure if it’s worth to save ~two bytes for that.
I think it's not worth complicating the field just to save two bytes.
But if we agree (for privacy reasons) that resolution of this field
should be reduced to week-level (as suggested by Jonas) or m
On Thu, Sep 07, 2017 at 09:47:16AM -0700, Jonas Schnelli via bitcoin-dev wrote:
> Thanks for the proposal.
>
> Three points it could see as possible improvements:
>
> 1.
> From what I know, the exact birthday in seconds doesn’t matter that much
> therefore it may be possible to just use 13 or 16
On Thu, Sep 07, 2017 at 06:37:19PM +0200, Pavol Rusnak via bitcoin-dev wrote:
> On 07/09/17 18:30, Kabuto Samourai wrote:
> > Why not make this block height, rather than a timestamp?
>
> Blockheight depends on the chain. XPUB is not tied to particular
> chain/coin.
>
> Also there are already cryp
Thanks for the proposal.
Three points it could see as possible improvements:
1.
From what I know, the exact birthday in seconds doesn’t matter that much
therefore it may be possible to just use 13 or 16bits to create a
representation in week from 2009-01-09 00:00 UTC. 13bits would give you 157
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 impl
On 07/09/17 18:30, Kabuto Samourai wrote:
> Why not make this block height, rather than a timestamp?
Blockheight depends on the chain. XPUB is not tied to particular
chain/coin.
Also there are already cryptocurrencies that do not use blockchain, but
directed acyclic graph (DAG) for storing transa
> Birthday
Why not make this block height, rather than a timestamp?
On Thu, Sep 7, 2017 at 11:25 AM, Pavol Rusnak 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 wall
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
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 outpu
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. Thi
On 07.09.2017 00:29, Pavol Rusnak via bitcoin-dev 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
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
15 matches
Mail list logo
