On Fri, Jun 15, 2018 at 8:54 AM, Russell O'Connor
wrote:
>
>> For codes designed for length 341 (the first length enough to support
>> 512 bits of data):
>> * correct 1 error = 3 checksum characters
>> * correct 2 errors = 7 checksum characters
>> * correct 3 errors = 11 checksum characters
>> *
> For codes designed for length 341 (the first length enough to support
> 512 bits of data):
> * correct 1 error = 3 checksum characters
> * correct 2 errors = 7 checksum characters
> * correct 3 errors = 11 checksum characters
> * correct 4 errors = 15 checksum characters
> * correct 5 errors =
On Tue, May 29, 2018 at 5:13 AM, Jonas Schnelli via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi
>
> If 520 bits are present, first 256 bits are the BIP32 chain code, to
> second 264
> bits (33 bytes) define the public key (according to BIP32)
>
In a 33 byte compressed public
On Sun, Jun 3, 2018 at 2:30 PM, Jonas Schnelli wrote:
>> If there is interest, I can construct a code + implementation for any
>> of these in a few days probably, once the requirements are clear.
>
> Yes. Please.
Here is an example BCH code for base32 data which adds 27 checksum
characters, and
> I have some concerns about the use of Bech32. It is designed for
> detecting 3 errors up to length 1023 (but is then picked specifically
> to support 4 errors up to length 89). However, for error correction
> this translates to just being able to efficiently correct 1 error
> (3/2, rounded down)
On Sun, Jun 3, 2018 at 9:51 AM, Jonas Schnelli via bitcoin-dev
wrote:
> Hi
>
> The BIP proposal is now available here:
> https://gist.github.com/jonasschnelli/68a2a5a5a5b796dc9992f432e794d719
>
> Reference C code is available here:
> https://github.com/jonasschnelli/bech32_keys
>
> Feedback,
Hi
The BIP proposal is now available here:
https://gist.github.com/jonasschnelli/68a2a5a5a5b796dc9992f432e794d719
Reference C code is available here:
https://github.com/jonasschnelli/bech32_keys
Feedback, criticism, etc. welcome!
Thanks
—
Jonas
signature.asc
Description: Message signed with
Hi
> - Visually Comparing two keys to find if they are same (Important)
> - Different wallet software could set different birthday/gap limit. creating
> different xpub/xprv for the same set of mathematically derived individual
> keys. This removes the decoupling between key and wallet metadata
On Wed, May 30, 2018 at 6:30 AM, shiva sitamraju via bitcoin-dev
wrote:
> The idea to add birthdate and gap limit sounds very good and addresses lots
> of problems users are facing.
>
> However, adding birthday to keys breaks two basic properties
>
> - Visually Comparing two keys to find if they
serialization/encoding format for key material
> (Jonas Schnelli)
>
>
> --
>
> Message: 1
> Date: Tue, 29 May 2018 11:13:37 +0200
> From: Jonas Schnelli
> To: Bitcoin Protocol Discussion
>
> Subject: [bitcoin-dev] New serialization/encoding
Hi
Extended public and private keys are defined in BIP32 [1].
Encoded extended private keys should not be confused with a wallet „seed“
(proposals like BIP39) while they can also partially serve the purpose to
„seed“ a wallet (there may be an overlap in the use-case).
Recovering a wallet by its
11 matches
Mail list logo
