From: "Jorge Timón" <jtimon@jtimon•cc>
To: Christophe Biocca <christophe.biocca@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] RFC: HD Bitmessage address derivation based on BIP-43
Date: Sun, 6 Sep 2015 04:09:52 +0200 [thread overview]
Message-ID: <CABm2gDorG0_e_1wZ6CNafA6LqDF89-M_FNt35Uik-pBCssoL4Q@mail.gmail.com> (raw)
In-Reply-To: <CANOOu=9Wn3kVC8eVQWLhMZpDKyVQ5Aus1=b-TsY=Ce9oud0xHg@mail.gmail.com>
On Sat, Sep 5, 2015 at 6:48 PM, Christophe Biocca
<christophe.biocca@gmail•com> wrote:
> I will point out that the current situation is not an accident:
> https://github.com/bitcoin/bips/pulls?utf8=%E2%9C%93&q=44 is a great
> place to get some context for what happened. I believe you can also
> find the other half of this discussion on the mailing list archives.
>
> The cointypes being simple integers was how the code worked as shipped
> (in the trezor), so changing the semantics after the fact wasn't a
> possibility.
>
> The BIP repository didn't want to constantly deal with updates
> unrelated to Bitcoin proper, so a decision was made to move that part
> of the standard to a repository willing to handle it.
This is in fact useful. The centralized registries themselves are fine
provided that we don't rely on having only one of them or in them
having the same values for the same chains.
Trezor can maintain its own too.
Future versions of Trezor could support full chain IDs instead of
these integers (or keep using these integers forever, whatever they
chose to do).
On Sat, Sep 5, 2015 at 7:03 PM, Luke Dashjr <luke@dashjr•org> wrote:
> On Saturday, September 05, 2015 11:17:52 AM Jorge Timón via bitcoin-dev wrote:
>> The "namespace" defined in BIP43 is acceptable. BIP44's is not:
>>
>> https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#Registered_c
>> oin_types
>>
>> It defines a centralized registry controlld by a single company instead of
>> having a way for different companies (or p2p chains like namecoin?) to
>> maintain competing registries.
>>
>> Even better, it could use a code deterministically generated from the chain
>> ID (the hash of the genesis block), completely removing the need for a
>> registry in the first place.
>
> No, because different chains may very well use the same genesis block.
Can you read my reasoning here?
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/010861.html
What I propose is retro-compatible, even for carelessly designed
chains (that allowed pre-mining) like FTC.
And provides securely unique IDs that don't require a centralized registry.
Maybe I should start a Chain IDs BIP...
prev parent reply other threads:[~2015-09-06 2:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-30 17:53 Justus Ranvier
2015-07-01 17:07 ` Kristov Atlas
2015-07-02 15:45 ` Justus Ranvier
2015-09-04 0:06 ` Luke Dashjr
2015-09-04 17:48 ` Justus Ranvier
2015-09-04 18:21 ` Luke Dashjr
2015-09-04 18:25 ` Justus Ranvier
2015-09-05 11:17 ` Jorge Timón
2015-09-05 16:48 ` Christophe Biocca
2015-09-06 2:09 ` Jorge Timón [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABm2gDorG0_e_1wZ6CNafA6LqDF89-M_FNt35Uik-pBCssoL4Q@mail.gmail.com \
--to=jtimon@jtimon$(echo .)cc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=christophe.biocca@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox