The benefit I see is avoiding reuse of keys between coins while not having
each wallet implementation have to know about each coin in order to scan
for transactions. Wallet X supports Doge and Bitcoin. If both used a
shared sequence of keys, say the first two end up Bitcoin, then 10 Doge,
then so
On Thu, Mar 27, 2014 at 5:21 PM, Pavol Rusnak wrote:
> Cointype in path is for separation purposes, not for identification.
I don't understand what that gains you.
--
Pieter
--
_
On 03/27/2014 05:14 PM, Pieter Wuille wrote:
> That said, I'm not convinced about the extra layers. The "cointype" in
> my opinion isn't necessary inside the derivation. There is already
> support (4 bytes!) for magic bytes in the serialized form. Inside
Cointype in path is for separation purposes
Just chiming in...
I'm not opposed to a more generic default key tree, but we need to
standardize this soon I believe. There are already existing code bases
that implement BIP32 wallets (and more are popping up...); just using
a separate one will result in lots of incompibilities.
That said, I'm
I'll make sure I understand your proposal better before commenting
much on it, but at a first glance, I don't see how it is incompatible
with 2 way peg and merged mining itself.
Why wouldn't you want merged mining for the root of your tree?
A miner could only chose a leaf block at a time, but it co
The idea was to use the magic number as the source for cointype. If it's
too big, as Tamas showed, perhaps a hash of it, and for coins without a
magic number, a hash of their name (or some unique identifier).
That being said, I agree with Andreas that something that is 90%
inter-operable seems ve
On 03/27/2014 04:57 PM, Allen Piscitello wrote:
> Don't most of these coins have a magic number already assigned that is
> unique? (0xD9B4BEF9 for Bitcoin, 0x0709110B for Testnet, FBC0XB6DB for
> Litecoin, etc...). This seems like a good candidate for identifying coins,
> and also supports Testnet
I think not all alts (will) have magic numbers, at least not those defined e.g.
with colored coins on top of an other chain.
Also note that the index should have MSB cleared as it would otherwise indicate
private derivation.
Regards,
Tamas Blummer
http://bitsofproof.com
On 27.03.2014, at 16:
Don't most of these coins have a magic number already assigned that is
unique? (0xD9B4BEF9 for Bitcoin, 0x0709110B for Testnet, FBC0XB6DB for
Litecoin, etc...). This seems like a good candidate for identifying coins,
and also supports Testnet cases well. Maybe there are some alts without
such a m
On Thu, Mar 27, 2014 at 3:09 AM, Tamas Blummer wrote:
> A notable suggestion was to instead of building a directory of magic numbers
> (like 0 for Bitcoin, 1 for Litecoin etc) use a hash of the word "Bitcoin",
> "Litecoin", "Dogecoin", so collosion is unlikely and
> cetral directory is not needed.
On Thu, Mar 27, 2014 at 02:49:32PM +0100, Thomas Voegtlin wrote:
>
>
> Le 27/03/2014 13:49, Mike Hearn a écrit :
> > Ah, BIP32 allows for a range of entropy sizes and it so happens that
> > they picked 256 bits instead of 128 bits.
> >
> > I'd have thought that there is a right answer for this. 2
>
> Related to this, here is another idea I would like to submit:
>
> Instead of using a "gap limit" (maximal number of consecutive unused
> addresses), I think we should get rid of the topology, and simply count
> the number of unused addresses since the beginning of the sequence.
For SPV wallets it's more complicated. There must always be a large
lookahead window for latency reasons. We can't query the entire database
because we don't know how far ahead the user is. So we have to assume there
might be a lot of transaction traffic and create a large window, to reduce
the cha
On 03/27/2014 02:53 PM, Thomas Voegtlin wrote:
> Note: Maybe we could just look at the first address of each account,
> instead of the first 10 ?
This is a possible optimization, but it adds unnecessary logic. Also it
does not decrease the number of required requests between a client and a
server
Good to hear the bip32 wallet structure is _so_ close to being standardised.
For MultiBit HD, we have put in support for 12/18/24 words but have the UI
'suggest' to use 12.
You can see this on the wallet creation wizard Gary recently blogged about:
https://multibit.org/blog/2014/03/26/multibit-hd-
Le 27/03/2014 14:44, Pavol Rusnak a écrit :
> On 03/27/2014 01:06 PM, Thomas Voegtlin wrote:
>> Yes, I was planning to increase the number of available unused addresses
>> to 10 or 20 in the bip32 version of Electrum.
>
> Also, we'd need to specify a "gap limit" for accounts as well. In TREZOR
>
Le 27/03/2014 13:49, Mike Hearn a écrit :
> Ah, BIP32 allows for a range of entropy sizes and it so happens that
> they picked 256 bits instead of 128 bits.
>
> I'd have thought that there is a right answer for this. 2^128 should not
> be brute forceable, and longer sizes have a cost in terms of
On 03/27/2014 01:06 PM, Thomas Voegtlin wrote:
> Yes, I was planning to increase the number of available unused addresses
> to 10 or 20 in the bip32 version of Electrum.
Also, we'd need to specify a "gap limit" for accounts as well. In TREZOR
we currently use 0, which means that the scan will sto
>
> To be honest, I have not carried out a comprehensive examination of
> server performance. What I can see is that Electrum servers are often
> slowed down when a wallet with a large number (thousands) of addresses
> shows up, and this is caused by disk seeks (especially on my slow VPS).
>
Yes t
Companies can have a Cert with their name via CAcert. It requires some work
though to get assured as an organisation.
Did you already think about what CA is to be trusted or do users need to do
that. The least good decision in my POV would be to accept OS/browser built in
CAs only.
Am 27.03.201
Le 27/03/2014 12:39, Mike Hearn a écrit :
> One issue that I have is bandwidth: Electrum (and mycelium) cannot
> watch as many addresses as they want, because this will create too
> much traffic on the servers. (especially when servers send utxo merkle
> proofs for each address, w
Obviously, SHA256 can't magically generate more entropy out of nothing, it
just stretches whatever is put in. If your seed was only 32 bits then
hashing wouldn't save you: every possible private key could easily be
calculated in advance.
On Thu, Mar 27, 2014 at 2:12 PM, Thomas Kerin wrote:
> Isn
Isn't the length of the seed arbitrary anyway? Once decoded using whatever
mnemonic implementation (electrums, or BIP0039) the bytestream is
immediately passed to HMAC-SHA256 to generate the master key. No matter
what your initial entropy is, it would be hashed anyway.
On Thu, Mar 27, 2014 at 12:
On Thu, Mar 27, 2014 at 9:28 AM, Mike Hearn wrote:
> By the way, I just noticed that greenaddress.it is creating seeds that have 24
> words instead of 12. Does anyone know what's up with that? They claim to be
> using BIP32 wallets so I wanted to see if they were using the default
> structure
> a
Ah, BIP32 allows for a range of entropy sizes and it so happens that they
picked 256 bits instead of 128 bits.
I'd have thought that there is a right answer for this. 2^128 should not be
brute forceable, and longer sizes have a cost in terms of making the seeds
harder to write down on paper. So sh
By the way, I just noticed that greenaddress.it is creating seeds that have
24 words instead of 12. Does anyone know what's up with that? They claim to
be using BIP32 wallets so I wanted to see if they were using the default
structure and if so, whether bitcoinj was compatible with it (before I
swi
Le 27/03/2014 12:30, Marek Palatinus a écrit :
> Ah, I forget to two things, which should be into the BIP as well:
>
> a) Gap factor for addresses; as Thomas mentioned, although some software
> can watch almost unlimited amount of unused addresses, this is serious
> concern for lightweight or ser
>
> One issue that I have is bandwidth: Electrum (and mycelium) cannot
> watch as many addresses as they want, because this will create too
> much traffic on the servers. (especially when servers send utxo merkle
> proofs for each address, which is not the case yet, but is planned)
>
This is surpr
On 03/26/2014 09:49 PM, Mike Hearn wrote:
>- cointype: This is zero for Bitcoin. This is here to support two
>things, one is supporting alt coins based off the same root seed. Right now
>nobody seemed very bothered about alt coins but sometimes feature requests
There is one "altcoin"
On 03/27/2014 08:09 AM, Tamas Blummer wrote:
> A notable suggestion was to instead of building a directory of magic numbers
> (like 0 for Bitcoin, 1 for Litecoin etc) use a hash of the word "Bitcoin",
> "Litecoin", "Dogecoin", so collosion is unlikely and
> cetral directory is not needed.
Nice i
Le 26/03/2014 21:49, Mike Hearn a écrit :
>
> * reserved is for "other stuff". I actually don't recall why we ended
> up with this. It may have been intended to split out multisig
> outputs etc from cointype. Marek, Thomas?
>
yes, this was intended to create multisig addresses from th
Le 27/03/2014 00:37, Andreas Schildbach a écrit :
> Thanks for starting the discussion on finding a better structure.
>
> For me, the most important thing is either we're 100% interoperable or
> 0%. There should not be anything inbetween, as users will delete seeds
> without knowing there is still
>
> But these cases are the norm, rather than the exception.
>
Well, you're lucky, you live in Berlin. Most of the payments I make with
Bitcoin are online, to websites. So this will differ between people.
I wonder how critical it is. Let's say you are paying for a meal. In your
head the place you
At this point I'm not sure how much further work people want to do on this:
I got the impression that Trezor will ship soon, and Thomas V seemed
satisfied too. I'm not sure we can get all wallets to be fully
interoperable given the flexibility inherent in BIP32 and people's
differing use cases.
An
We had a similar meeting with Andreas Schildbach (Android Bitcoin Wallet), Jan
Moller, Andreas Petersson (Mycelium), Thomas V (Electrum), Tamas Blummer,
Tamas Bartfai (Bits of Proof)
at the Inside Bitcoin Conference in Berlin.
I remember that there were different opinions on how to use a hierar
35 matches
Mail list logo
