On Sat, 13 Jan 2024 at 10:53, Leslie <0300dbd...@protonmail.com> wrote:
> Developments like aezeed[1] or Electrum V2[2] also demonstrate that the
> standard BIP39 entropy might not always suffice for specific applications,
> leading to alternative standards being developed.
> This reality
Hi Leslie, hi list!
BIP39 author here. Not having version was a design decision, not accidental
omission.
When designing BIP39 we were striving for maximum interoperability. There
are thousands of BIP39 applications and all of them have 100% interoperable
way how to share entropy using a single
Here's my idea for a clean API:
1. `is_segwit()` returns true for a p2tr output
2. a function `segwit_version()` which returns an int according to segwit
version used
3. helper functions like `is_p2wpkh()`, `is_p2tr()`, `is_p2wsh()` for all
script types which all return a bool
On Fri, 11 Aug
Thanks Andrew!
New draft makes it much more obvious what are the differences between
Codex32 and SLIP-0039 scheme.
--
Best Regards / S pozdravom,
Pavol "Stick" Rusnak
Co-Founder, SatoshiLabs
___
bitcoin-dev mailing list
Hi!
The BIP states that its only advantage over SLIP-0039, which has been used
in production for nearly three years (in at at least 3 SW/HW wallet
implementations), is that it aims to be simple enough for hand computation.
However, the BIP also indicates that "details of hand computation are
There is already a JSON standard that has been already used in the wild for
the last 7 years described in SLIP-0015 (mentioned by Clark in this
thread). No need to reinventing the wheel again.
On Wed 24. 8. 2022 at 21:44, Ryan Havar via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
Hi Ali!
Nice work. Since it seems this is a strict superset of BIP137, why not just
focus on things that you are adding (Taproot) while saying your BIP is an
expansion of BIP137?
Your approach make it unnecessarily hard to figure out whether you are
changing anything in handling of ECDSA
On Wed, 27 Jul 2022 at 00:28, Andrew Chow
wrote:
> However I don't see why this couldn't generalize to any sized tuples. As
> long as the tuples are all the same length, and the limit is one tuple per
> key expression, then we don't get any combinatorial blowup issues.
>
I think it's worthwhile
Thanks Andrew for this BIP. We've been already using this for quite some
time for Trezor in production.
Just one clarification: Should , , ... also
work or we only aim to support only tuples of exactly two values?
On Tue, 26 Jul 2022 at 23:51, Andrew Chow via bitcoin-dev <
There is. Just encode the index of permutation used to scramble the
otherwise sorted list. For 12 words you need to store 12! = ~32 bits so 3
words should be enough.
Repetitions make this more difficult, though.
On Thu 7. 7. 2022 at 19:41, Bram Cohen via bitcoin-dev <
Trezor recovery cards look like this what addresses the issue:
https://wiki.trezor.io/images/Seed_card_example.jpg
1. Each word has a box around it.
2. You write the words one under the other, not next to each other.
On Mon, 17 Jan 2022 at 23:38, Jeremy via bitcoin-dev <
+1 from the author of BIP43, BIP44 and BIP84. The proposed BIP follows this
pattern nicely.
--
Best Regards / S pozdravom,
Pavol "stick" Rusnak
Co-founder and CTO, SatoshiLabs
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
Please read the Bitcoin whitepaper. It's a very interesting read.
--
Best Regards / S pozdravom,
Pavol "stick" Rusnak
Co-founder and CTO, SatoshiLabs
On Sat, May 15, 2021, 23:57 Michael Fuhrmann via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hello,
>
> Bitcoin should create
If block compression is going to be considered, zstd provides better
properties than the competition.
Especially for the decompression. [1]
[1] https://github.com/facebook/zstd
--
Best Regards / S pozdravom,
Pavol "stick" Rusnak
Co-founder and CTO, SatoshiLabs
> ENCRYPTION_KEY = SHA256(SHA256(TOKEN))
This scheme might be vulnerable to rainbow table attack.
The following scheme might be more secure:
DESCRIPTION = ASCII description provided by user
NONCE = 256-bit random number
ENCRYPTION_KEY = hmac-sha256(key=NONCE, msg=DESCRIPTION)
Coordinator
I applaud this effort!
We tried to document the 48 path usage in this document:
https://github.com/trezor/trezor-firmware/blob/master/docs/misc/purpose48.md
The only difference I can spot is that our document also documents
script_type=0 which is for the raw BIP-11 multisig. While almost not
https://github.com/bitcoin/bips/blob/master/bip-0069.mediawiki
--
Best Regards / S pozdravom,
Pavol "stick" Rusnak
CTO, SatoshiLabs
On Thu, Apr 30, 2020, 10:21 SatoshiSingh via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi list. I've been a lurker for quite sometime and this
On 20/03/2020 16:44, Ethan Kosakovsky via bitcoin-dev wrote:
> I would like to present a proposal for discussion and peer review
I read your proposal twice and I still don't know what kind of problem
are you trying to solve.
This should be obvious from the "Abstract" and it's bad if it's not.
I'd rather see something using Base58 or even better Bech32. Base64 is not
URL/QR code friendly.
On Tue, Dec 24, 2019, 18:06 Chris Belcher via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I've recently been playing around with descriptors, and they are very
> nice to work with.
; Regards
>
> Aymeric
> Le 03/04/2019 à 11:19, Pavol Rusnak via bitcoin-dev a écrit :
>
> I am the author of the wordlist. Feel free to use it without any
> restrictions.
>
> However, we are finalizing SLIP39 standard for splitting shares which uses
> a different wordl
I am the author of the wordlist. Feel free to use it without any
restrictions.
However, we are finalizing SLIP39 standard for splitting shares which uses
a different wordlist with better properties. It might be more suitable for
your project.
See
On 15/02/2019 16:18, Luke Dashjr via bitcoin-dev wrote:
>> The proposed proof-file format provides a standard way of combining
>> multiple proofs and associated metadata. The specification of the format
>> is in the Protocol
>> Buffershttps://github.com/protocolbuffers/protobuf/ format.
>
>
On 22/12/2018 00:58, Aymeric Vitte via bitcoin-dev wrote:
> Has anybody already looked at this: given N randomly chosen words
> belonging to a BIP39 2048 words dictionary, what is the probability to
> get a "valid" BIP39 seed (ie with the right checksum)?
1:256 for 24 words
1:16 for 12 words
Your solution in the second part of the email does not solve the problem
you indicated in the first part of your email.
On Sun, Oct 21, 2018, 23:41 Ryan Havar via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Right now it's just *way* too easy to spot the boundaries between
>
On 11/01/18 00:47, Gregory Maxwell wrote:
> I believe that can be avoided by having the computer do somewhat more
> work and checking the consistency after the fact.
>
> (or for decode time, having a check value under the encryption...)
Can you describe these two methods more in detail? How
On 09/01/18 16:12, Pavol Rusnak via bitcoin-dev wrote:
> On 09/01/18 00:47, Gregory Maxwell wrote:
>> Have you considered using blind host-delegated KDFs, where the KDF
>> runs on the user's computer instead of the hardware wallet, but the
>> computer doesn't learn any
On 08/01/18 13:45, Peter Todd wrote:
> Can you explain _exactly_ what scenario the "plausible deniability" feature
> refers to?
https://doc.satoshilabs.com/trezor-user/advanced_settings.html#multi-passphrase-encryption-hidden-wallets
--
Best Regards / S pozdravom,
Pavol "stick" Rusnak
CTO,
On 08/01/18 05:22, Gregory Maxwell wrote:
>> https://github.com/satoshilabs/slips/blob/master/slip-0039.md
Hey Gregory!
Thanks for looking into the scheme. I appreciate your time!
> This specification forces the key being used through a one way
> function, -- so you cannot take a pre-existing
On 05/01/18 14:58, nullius via bitcoin-dev wrote:
> I propose and request as an enhancement that the BIP 39 wordlist set
> should specify canonical native language strings to identify each
> wordlist, as well as short ASCII language codes. At present, the
> languages are identified only by their
On 08/12/17 19:25, Dan Bryant via bitcoin-dev wrote:
> I know there are posts, and an issue opened against it, but is there
> anyone writing a BIP for Sign / Verify message against a SegWit address?
Dan, are you still planning to write this BIP?
--
Best Regards / S pozdravom,
Pavol "stick"
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
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
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
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
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
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
On 05/09/17 12:25, Thomas Voegtlin via bitcoin-dev wrote:
> == === ===
> VersionPrefix Description
> == === ===
> 0x0488ade4 xprvP2PKH or P2SH
> 0x0488b21e xpubP2PKH or P2SH
>
On 05/09/17 09:10, shiva sitamraju via bitcoin-dev wrote:
> 0x042393df , sxpr , segwit mainnet private key
> 0x04239377 , sxpb , segwit mainnet public key
> 0x04222463 , stpb , segwit testnet public key
> 0x042224cc , stpr , segwit testnet private key
I am fine with both your proposal and
On 14/05/16 18:14, Jonas Schnelli wrote:
> AFAIK: Bip39 import (cross-wallet) is not supported by Schildbachs
> android wallet [1] and Electrum [2] and Breadwallet [3].
They are not BIP44 compatible wallets. This thread is about BIP44.
> * What if the "old" wallet has used more then 1000
On 14/05/16 09:00, Andreas Schildbach via bitcoin-dev wrote:
> The whole idea of BIP43 (which BIP44 bases on) is that how these BIPs
> define balance retrieval never changes. This is to make sure you always
> see the same balance on "same BIP" wallets (and same seed of course).
This! Thanks
On 14/05/16 10:16, Jonas Schnelli via bitcoin-dev wrote:
> Importing a bip32 wallet (bip44 or not) is still an expert job IMO.
That's simply not true. All reasonable wallets (reasonable = user
oriented) now use BIP39 mnemonic for doing exactly this.
--
Best Regards / S pozdravom,
Pavol "stick"
On 13/05/16 18:59, Aaron Voisine wrote:
> This scheme is independent of the number of accounts. It works with BIP44
> as well as BIP43 purpose 0, or any other BIP43 purpose/layout. Instead of
> overloading the account index to indicate the type of address, you use the
> chain index, which is
On 13/05/16 18:03, Aaron Voisine wrote:
> I like the idea of specifying the type of address as a bit field flag.
> 0x8000 is already used to specify hardened derivation, so 0x4000
> would be the next available to specify witness addresses. This is
> compatible with existing accounts and
On 13/05/16 15:16, Daniel Weigl via bitcoin-dev wrote:
> 2) Define a new derivation path, parallel to Bip44, but a different
> 'purpose' (eg. ' instead of 44'). Let the user choose
> which account he want to add ("Normal account", "Witness account").
We had quite a long discussion in our
On 08/05/16 15:48, Marek Palatinus via bitcoin-dev wrote:
> unambiguously be used to refer to an idea. My suggestion would be to write
> a new BIP that overrides parts of BIP32, and then put a note in BIP32 that
> a better mechanism is available that is unlikely to change things in
> reality for
On 21/04/16 14:08, Marek Palatinus via bitcoin-dev wrote:
> Sipa, you are probably the most competent to answer this.
> Could you please tell us your opinion? For me, this is
> straightforward, backward compatible fix and I like it a lot.
> Not sure about the process of changing "Final" BIP
On 21/04/16 17:28, Eric Lombrozo via bitcoin-dev wrote:
> I don't think we've ever had to handle this case.
This is the main problem: we are not sure, because not a lot of software
does this checks. Also even if you do check, it's hard to handle an
exception (you can't always skip - what if the
47 matches
Mail list logo
