* [bitcoin-dev] RFC: HD Bitmessage address derivation based on BIP-43
@ 2015-06-30 17:53 Justus Ranvier
2015-07-01 17:07 ` Kristov Atlas
2015-09-04 0:06 ` Luke Dashjr
0 siblings, 2 replies; 10+ messages in thread
From: Justus Ranvier @ 2015-06-30 17:53 UTC (permalink / raw)
To: bitcoin-dev
Monetas has developed a Bitmessage address derivation method from an
HD seed based on BIP-43.
https://github.com/monetas/bips/blob/bitmessage/bip-bm01.mediawiki
We're proposing this as a BIP per the BIP-43 recommendation in order
to reserve a purpose code.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] RFC: HD Bitmessage address derivation based on BIP-43
2015-06-30 17:53 [bitcoin-dev] RFC: HD Bitmessage address derivation based on BIP-43 Justus Ranvier
@ 2015-07-01 17:07 ` Kristov Atlas
2015-07-02 15:45 ` Justus Ranvier
2015-09-04 0:06 ` Luke Dashjr
1 sibling, 1 reply; 10+ messages in thread
From: Kristov Atlas @ 2015-07-01 17:07 UTC (permalink / raw)
To: Justus Ranvier; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 605 bytes --]
Hi Justus,
What are the potential applications for this BIP?
-Kr
On Jun 30, 2015 1:53 PM, "Justus Ranvier" <justus.ranvier@monetas•net>
wrote:
> Monetas has developed a Bitmessage address derivation method from an
> HD seed based on BIP-43.
>
>
> https://github.com/monetas/bips/blob/bitmessage/bip-bm01.mediawiki
>
>
> We're proposing this as a BIP per the BIP-43 recommendation in order
> to reserve a purpose code.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 1218 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] RFC: HD Bitmessage address derivation based on BIP-43
2015-07-01 17:07 ` Kristov Atlas
@ 2015-07-02 15:45 ` Justus Ranvier
0 siblings, 0 replies; 10+ messages in thread
From: Justus Ranvier @ 2015-07-02 15:45 UTC (permalink / raw)
To: Kristov Atlas; +Cc: bitcoin-dev
The primary purpose is to allow Bitmessage users to benefit from
eternal key backups by generating their addresses from a seed.
In addition, they can use the same seed for a Bitcoin wallet and a
Bitmessage client.
This method also enables future use cases where senders calculate
Bitmessage addresses based on a recipient's extended public key and
some other index value.
On Wed, Jul 1, 2015 at 12:07 PM, Kristov Atlas
<kristovatlas.lists@gmail•com> wrote:
> Hi Justus,
>
> What are the potential applications for this BIP?
>
> -Kr
>
> On Jun 30, 2015 1:53 PM, "Justus Ranvier" <justus.ranvier@monetas•net>
> wrote:
>>
>> Monetas has developed a Bitmessage address derivation method from an
>> HD seed based on BIP-43.
>>
>>
>> https://github.com/monetas/bips/blob/bitmessage/bip-bm01.mediawiki
>>
>>
>> We're proposing this as a BIP per the BIP-43 recommendation in order
>> to reserve a purpose code.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] RFC: HD Bitmessage address derivation based on BIP-43
2015-06-30 17:53 [bitcoin-dev] RFC: HD Bitmessage address derivation based on BIP-43 Justus Ranvier
2015-07-01 17:07 ` Kristov Atlas
@ 2015-09-04 0:06 ` Luke Dashjr
2015-09-04 17:48 ` Justus Ranvier
1 sibling, 1 reply; 10+ messages in thread
From: Luke Dashjr @ 2015-09-04 0:06 UTC (permalink / raw)
To: bitcoin-dev; +Cc: Justus Ranvier
On Tuesday, June 30, 2015 5:53:05 PM Justus Ranvier wrote:
> Monetas has developed a Bitmessage address derivation method from an
> HD seed based on BIP-43.
>
> https://github.com/monetas/bips/blob/bitmessage/bip-bm01.mediawiki
>
> We're proposing this as a BIP per the BIP-43 recommendation in order
> to reserve a purpose code.
Bitmessage is not Bitcoin, thus this falls outside the scope of the BIP
process. Since BIP 43 is still a draft, I propose modifying it to refer non-
Bitcoin purpose codes to the SLIP repository:
https://doc.satoshilabs.com/slips/
Luke
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] RFC: HD Bitmessage address derivation based on BIP-43
2015-09-04 0:06 ` Luke Dashjr
@ 2015-09-04 17:48 ` Justus Ranvier
2015-09-04 18:21 ` Luke Dashjr
2015-09-05 11:17 ` Jorge Timón
0 siblings, 2 replies; 10+ messages in thread
From: Justus Ranvier @ 2015-09-04 17:48 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1.1: Type: text/plain, Size: 727 bytes --]
On 09/03/2015 07:06 PM, Luke Dashjr via bitcoin-dev wrote:
> Since BIP 43 is still a draft, I propose modifying it to refer non-
> Bitcoin purpose codes to the SLIP repository:
> https://doc.satoshilabs.com/slips/
What benefit is created by delegating the BIP-43 namespace management to
that company in particular?
BIP-43 as it is currently composed provides the convenient feature of
purpose codes matching the BIP number. Moving purpose codes to a
separate namespace add complexity to its usage for no discernible benefit.
--
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus@openbitcoinprivacyproject•org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
[-- Attachment #1.2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 18667 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] RFC: HD Bitmessage address derivation based on BIP-43
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
1 sibling, 1 reply; 10+ messages in thread
From: Luke Dashjr @ 2015-09-04 18:21 UTC (permalink / raw)
To: Justus Ranvier; +Cc: bitcoin-dev
On Friday, September 04, 2015 5:48:48 PM Justus Ranvier wrote:
> On 09/03/2015 07:06 PM, Luke Dashjr via bitcoin-dev wrote:
> > Since BIP 43 is still a draft, I propose modifying it to refer non-
> >
> > Bitcoin purpose codes to the SLIP repository:
> > https://doc.satoshilabs.com/slips/
>
> What benefit is created by delegating the BIP-43 namespace management to
> that company in particular?
Feel free to create a company-independent repository instead.
Although I don't think SLIPs are intended to be biased toward their company.
> BIP-43 as it is currently composed provides the convenient feature of
> purpose codes matching the BIP number. Moving purpose codes to a
> separate namespace add complexity to its usage for no discernible benefit.
This is not Bitcoin's problem... Polluting the BIP repository with N non-
Bitcoin related specifications would be.
Luke
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] RFC: HD Bitmessage address derivation based on BIP-43
2015-09-04 18:21 ` Luke Dashjr
@ 2015-09-04 18:25 ` Justus Ranvier
0 siblings, 0 replies; 10+ messages in thread
From: Justus Ranvier @ 2015-09-04 18:25 UTC (permalink / raw)
To: Luke Dashjr; +Cc: bitcoin-dev
[-- Attachment #1.1: Type: text/plain, Size: 622 bytes --]
On 09/04/2015 01:21 PM, Luke Dashjr wrote:
> This is not Bitcoin's problem... Polluting the BIP repository with N non-
> Bitcoin related specifications would be.
HD generation of keypairs from a single seed for many non-conflicting
uses is a valuable and useful technique.
Intentionally making a useful technology less useful because assigning
non-colliding numbers is too hard is a strange approach to software
engineering.
--
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus@openbitcoinprivacyproject•org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
[-- Attachment #1.2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 18667 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] RFC: HD Bitmessage address derivation based on BIP-43
2015-09-04 17:48 ` Justus Ranvier
2015-09-04 18:21 ` Luke Dashjr
@ 2015-09-05 11:17 ` Jorge Timón
2015-09-05 16:48 ` Christophe Biocca
1 sibling, 1 reply; 10+ messages in thread
From: Jorge Timón @ 2015-09-05 11:17 UTC (permalink / raw)
To: Justus Ranvier; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1538 bytes --]
On Sep 4, 2015 7:56 PM, "Justus Ranvier via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> On 09/03/2015 07:06 PM, Luke Dashjr via bitcoin-dev wrote:
> > Since BIP 43 is still a draft, I propose modifying it to refer non-
> > Bitcoin purpose codes to the SLIP repository:
> > https://doc.satoshilabs.com/slips/
>
> What benefit is created by delegating the BIP-43 namespace management to
> that company in particular?
>
> BIP-43 as it is currently composed provides the convenient feature of
> purpose codes matching the BIP number. Moving purpose codes to a
> separate namespace add complexity to its usage for no discernible benefit.
The "namespace" defined in BIP43 is acceptable. BIP44's is not:
https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#Registered_coin_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.
> --
> Justus Ranvier
> Open Bitcoin Privacy Project
> http://www.openbitcoinprivacyproject.org/
> justus@openbitcoinprivacyproject•org
> E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 2331 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] RFC: HD Bitmessage address derivation based on BIP-43
2015-09-05 11:17 ` Jorge Timón
@ 2015-09-05 16:48 ` Christophe Biocca
2015-09-06 2:09 ` Jorge Timón
0 siblings, 1 reply; 10+ messages in thread
From: Christophe Biocca @ 2015-09-05 16:48 UTC (permalink / raw)
To: Jorge Timón; +Cc: Bitcoin Dev
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.
On 5 September 2015 at 07:17, Jorge Timón
<bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> On Sep 4, 2015 7:56 PM, "Justus Ranvier via bitcoin-dev"
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>> On 09/03/2015 07:06 PM, Luke Dashjr via bitcoin-dev wrote:
>> > Since BIP 43 is still a draft, I propose modifying it to refer non-
>> > Bitcoin purpose codes to the SLIP repository:
>> > https://doc.satoshilabs.com/slips/
>>
>> What benefit is created by delegating the BIP-43 namespace management to
>> that company in particular?
>>
>> BIP-43 as it is currently composed provides the convenient feature of
>> purpose codes matching the BIP number. Moving purpose codes to a
>> separate namespace add complexity to its usage for no discernible benefit.
> The "namespace" defined in BIP43 is acceptable. BIP44's is not:
>
> https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#Registered_coin_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.
>
>> --
>> Justus Ranvier
>> Open Bitcoin Privacy Project
>> http://www.openbitcoinprivacyproject.org/
>> justus@openbitcoinprivacyproject•org
>> E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] RFC: HD Bitmessage address derivation based on BIP-43
2015-09-05 16:48 ` Christophe Biocca
@ 2015-09-06 2:09 ` Jorge Timón
0 siblings, 0 replies; 10+ messages in thread
From: Jorge Timón @ 2015-09-06 2:09 UTC (permalink / raw)
To: Christophe Biocca; +Cc: Bitcoin Dev
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...
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-09-06 2:09 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-30 17:53 [bitcoin-dev] RFC: HD Bitmessage address derivation based on BIP-43 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 is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox