On Sat, Apr 26, 2014 at 6:08 AM, Thomas Voegtlin wrote:
> Perhaps the only thing that needs to be standardized is the order of
> public keys in the redeem script: I think they should be sorted, so that
> the p2sh address does not depend on the order of pubkeys.
Yes. That solution is already impl
Ah, I see now. Thanks. And actually now I re-read it, Manuel's explanation
was clear, it just didn't sink in for some reason.
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eX
On 04/26/2014 04:33 PM, Mike Hearn wrote:
>
> Let's assume we use one shared branch for everyone. Then two
> cosigners could need a new receiving address at the same time, and
> get the next unused address on that branch.
>
> This is the part I struggle to understand. There is no share
>
> Let's assume we use one shared branch for everyone. Then two cosigners
> could need a new receiving address at the same time, and get the next
> unused address on that branch.
>
This is the part I struggle to understand. There is no shared branch
because each user/cosigner has their own unique
On Apr 26, 2014 6:43 AM, "Mike Hearn" wrote:
>
> I'm not sure I understand why you need any special structure for this at
all. The way I'd do it is just use regular HD wallets for everyone, of the
regular form, and then swap the watching keys. Why do people need to be
given a cosigner index at all
Le 26/04/2014 11:43, Mike Hearn a écrit :
> I'm not sure I understand why you need any special structure for this at
> all. The way I'd do it is just use regular HD wallets for everyone, of the
> regular form, and then swap the watching keys. Why do people need to be
> given a cosigner index at a
I'm not sure I understand why you need any special structure for this at
all. The way I'd do it is just use regular HD wallets for everyone, of the
regular form, and then swap the watching keys. Why do people need to be
given a cosigner index at all, given that they all have unique root keys
anyway
I will just chime in that I've been working on a similar spec for Armory
to implement P2SH multisig and I came up with basically an identical
scheme. I think you covered most of what is needed. The one thing I
did differently was try to match the BIP 32 structure, by keeping the
original 3 level
Le 24/04/2014 09:21, Gregory Maxwell a écrit :
>
> It doesn't appear to me that reoccurring payments, receive accounts,
> multisig addresses, etc can be used with this proposal, but instead
> you must use a different purpose code and another BIP and are not
> compatible with the draft here.
>
>
Right. So part of this is my fault, I'm afraid, because I do not intend to
implement any kind of subwallet/account support in bitcoinj. My reasons are:
1. The bitcoinj API already lets you create and use multiple wallets.
What's more, because of the desire to do key rotation (think rotating
Le 24/04/2014 09:10, Pieter Wuille a écrit :
> To clarify:
> BIP64 has a much stricter definition for accounts than BIP32.
>
> In BIP32, it is not well specified what accounts are used for. They
> can be used for "subwallets", "receive accounts" (as in bitcoind's
> account feature), "recurring p
On Thu, Apr 24, 2014 at 12:10 AM, Pieter Wuille wrote:
> On Thu, Apr 24, 2014 at 8:54 AM, Thomas Voegtlin wrote:
>>> Why do clients need to use the features in BIP 64? If Electrum doesn't want
>>> to
>>> use accounts, [...]
>>
>> To clarify:
>> Electrum plans to have bip32 accounts; Multibit wil
On Thu, Apr 24, 2014 at 8:54 AM, Thomas Voegtlin wrote:
>> Why do clients need to use the features in BIP 64? If Electrum doesn't want
>> to
>> use accounts, [...]
>
> To clarify:
> Electrum plans to have bip32 accounts; Multibit will not, afaik.
To clarify:
BIP64 has a much stricter definition
Le 23/04/2014 21:44, Luke-Jr a écrit :
> On Wednesday, April 23, 2014 7:29:04 PM Pavol Rusnak wrote:
>>
>> Examples: Electrum does not want to use accounts [...]
> Why do clients need to use the features in BIP 64? If Electrum doesn't want
> to
> use accounts, [...]
To clarify:
Electrum plans
On Wednesday, April 23, 2014 9:33:48 PM Pavol Rusnak wrote:
> On 04/23/2014 11:22 PM, Gregory Maxwell wrote:
> > Hopefully it would be clarified as only a MUST NOT do so silently...
> > "I have funds split across two wallets and it WONT LET ME SPEND THEM"
> > sounds like a terrible user experience.
On Wed, Apr 23, 2014 at 2:42 PM, Pieter Wuille wrote:
> In that case, maybe it makes sense to define another purpose id
> without accounts as well already.
>
> I believe many simple wallets will find multiple subwallets too
> burdening for the user experience, or not worth the technical
> complexi
On 04/23/2014 11:42 PM, Pieter Wuille wrote:
> In that case, maybe it makes sense to define another purpose id
> without accounts as well already.
>
> I believe many simple wallets will find multiple subwallets too
> burdening for the user experience, or not worth the technical
> complexity.
Righ
On Wed, Apr 23, 2014 at 11:33 PM, Pavol Rusnak wrote:
> On 04/23/2014 11:22 PM, Gregory Maxwell wrote:
>> Hopefully it would be clarified as only a MUST NOT do so silently...
>> "I have funds split across two wallets and it WONT LET ME SPEND THEM"
>> sounds like a terrible user experience. :)
>
>
On 04/23/2014 11:22 PM, Gregory Maxwell wrote:
> Hopefully it would be clarified as only a MUST NOT do so silently...
> "I have funds split across two wallets and it WONT LET ME SPEND THEM"
> sounds like a terrible user experience. :)
That is a subjective matter. To me it makes PERFECT SENSE that
On 04/23/2014 11:18 PM, Luke-Jr wrote:
> Only a very niche user base needs funds isolated...
Our users do and we are creating this BIP for them, because we love them. ;)
--
Best Regards / S pozdravom,
Pavol Rusnak
--
On Wed, Apr 23, 2014 at 2:18 PM, Luke-Jr wrote:
> How do you get the more expected/usual behaviour of mixing funds between
> accounts? Only a very niche user base needs funds isolated...
Hopefully it would be clarified as only a MUST NOT do so silently...
"I have funds split across two wallets an
On Wednesday, April 23, 2014 9:06:26 PM Pavol Rusnak wrote:
> On 04/23/2014 10:54 PM, Pieter Wuille wrote:
> > Would you consider software which scans all accounts as specified by
> > BIP64, but has no user interface option to distinguish them in any
> > way, view them independently, and has no abi
On Wed, Apr 23, 2014 at 10:54 PM, Pieter Wuille wrote:
>
> Would you consider software which scans all accounts as specified by
> BIP64, but has no user interface option to distinguish them in any
> way, view them independently, and has no ability to keep the coins
> apart... compatible with BIP64
On 04/23/2014 10:54 PM, Pieter Wuille wrote:
> Would you consider software which scans all accounts as specified by
> BIP64, but has no user interface option to distinguish them in any
> way, view them independently, and has no ability to keep the coins
> apart... compatible with BIP64?
This is no
On Wednesday, April 23, 2014 8:43:57 PM Pavol Rusnak wrote:
> On 04/23/2014 10:41 PM, Luke-Jr wrote:
> > I don't see how. The user knows he has money in different subwallets. As
> > long as he has a way to specify which subwallet he is accessing in
> > single-subwallet clients, there shouldn't be a
On Wed, Apr 23, 2014 at 10:43 PM, Pavol Rusnak wrote:
> On 04/23/2014 10:41 PM, Luke-Jr wrote:
>> I don't see how. The user knows he has money in different subwallets. As long
>> as he has a way to specify which subwallet he is accessing in
>> single-subwallet
>> clients, there shouldn't be a pro
On 04/23/2014 10:41 PM, Luke-Jr wrote:
> I don't see how. The user knows he has money in different subwallets. As long
> as he has a way to specify which subwallet he is accessing in
> single-subwallet
> clients, there shouldn't be a problem.
Right. But these clients have no right to call thems
On Wednesday, April 23, 2014 8:35:50 PM Pavol Rusnak wrote:
> On 04/23/2014 10:32 PM, Luke-Jr wrote:
> > f) I missed the part where BIP 32 redefined "account" to mean "subwallet"
> > instead of what has traditionally been called "account" in Bitcoin.
>
> Ah, okay. The last time I saw Bitcoin-qt it
On 04/23/2014 10:32 PM, Luke-Jr wrote:
> f) I missed the part where BIP 32 redefined "account" to mean "subwallet"
> instead of what has traditionally been called "account" in Bitcoin.
Ah, okay. The last time I saw Bitcoin-qt it was still using independent
addresses.
> In that case, single-subwa
On Wednesday, April 23, 2014 8:16:45 PM Pavol Rusnak wrote:
> On 04/23/2014 10:09 PM, Luke-Jr wrote:
> > Scan all branches for UTXOs, then you have the balance for the wallet.
> > Account balances are metadata, so cannot be known from the seed alone.
> > If you want to have a way to restore account
On 23.04.2014, at 22:09, Luke-Jr wrote:
> On Wednesday, April 23, 2014 8:04:03 PM Pavol Rusnak wrote:
>> On 04/23/2014 10:01 PM, Luke-Jr wrote:
>>> Yes, it should scan all possible (under the BIP-defined structure)
>>> branches regardless of which features it supports.
>>
>> So you suggest to sc
On 04/23/2014 10:09 PM, Luke-Jr wrote:
> Scan all branches for UTXOs, then you have the balance for the wallet.
> Account
> balances are metadata, so cannot be known from the seed alone. If you want to
> have a way to restore accounts, you must define some more detailed wallet
> file
> format
I believe Luke means scanning chains as defined by the structure, but not
handing out addresses from other accounts than the first one.
That's certainly a possibly way to compatibly implement BIP64, but it
doesn't reduce all that much complexity. I hope people would choose that
over defining their
On Wednesday, April 23, 2014 8:04:03 PM Pavol Rusnak wrote:
> On 04/23/2014 10:01 PM, Luke-Jr wrote:
> > Yes, it should scan all possible (under the BIP-defined structure)
> > branches regardless of which features it supports.
>
> So you suggest to scan for accounts, show balances but don't allow
That's the point. BIP64 specifies such a structure, and you have to scan
all that it defines.
If you want to write wallet software that does not have the complexity to
deal with just one account, it is not BIP64 compliant. It could try to
define its own purpose system, with a hierarchy without acc
On 04/23/2014 10:01 PM, Luke-Jr wrote:
> Yes, it should scan all possible (under the BIP-defined structure) branches
> regardless of which features it supports.
So you suggest to scan for accounts, show balances but don't allow user
to spend them? Does not seem right to me.
--
Best Regards / S
On 23.04.2014, at 22:02, Luke-Jr wrote:
> On Wednesday, April 23, 2014 8:01:16 PM Tamas Blummer wrote:
>> On 23.04.2014, at 21:55, Luke-Jr wrote:
>>> Any wallet should import all the coins just fine, it just wouldn't *use*
>>> any account other than 0. Remember addresses are used to receive
>>>
On Wednesday, April 23, 2014 8:01:16 PM Tamas Blummer wrote:
> On 23.04.2014, at 21:55, Luke-Jr wrote:
> > Any wallet should import all the coins just fine, it just wouldn't *use*
> > any account other than 0. Remember addresses are used to receive
> > bitcoins; once the UTXOs are in the wallet, t
On 23.04.2014, at 21:55, Luke-Jr wrote:
> Any wallet should import all the coins just fine, it just wouldn't *use* any
> account other than 0. Remember addresses are used to receive bitcoins; once
> the UTXOs are in the wallet, they are no longer associated with the address
> or
> any other d
On Wednesday, April 23, 2014 7:57:46 PM slush wrote:
> On Wed, Apr 23, 2014 at 9:55 PM, Luke-Jr wrote:
> > Any wallet should import all the coins just fine, it just wouldn't *use*
> > any
> > account other than 0. Remember addresses are used to receive bitcoins;
> > once the UTXOs are in the walle
On Wed, Apr 23, 2014 at 9:55 PM, Luke-Jr wrote:
> Any wallet should import all the coins just fine, it just wouldn't *use*
> any
> account other than 0. Remember addresses are used to receive bitcoins; once
> the UTXOs are in the wallet, they are no longer associated with the
> address or
> any o
On Wednesday, April 23, 2014 7:49:38 PM Pavol Rusnak wrote:
> On 04/23/2014 09:44 PM, Luke-Jr wrote:
> > Why do clients need to use the features in BIP 64? If Electrum doesn't
> > want to use accounts, then it can just use account 0 for everything.
> > Refund chains are
>
> As Andreas wrote earlie
On 04/23/2014 09:44 PM, Luke-Jr wrote:
> Why do clients need to use the features in BIP 64? If Electrum doesn't want
> to
> use accounts, then it can just use account 0 for everything. Refund chains
> are
As Andreas wrote earlier in this thread: "There is no "bare minimum".
Either you implemen
We do not want BIP64 to be incompatible with BIP32 in any way. BIP64 is
just set of some recommendations for wallet developers how to browse bip32
tree.
Modifying serialization format would break the compatibility.
However we have our solution for storing wallet birth time, which is out of
scope
On Wednesday, April 23, 2014 7:29:04 PM Pavol Rusnak wrote:
> On 04/23/2014 09:00 PM, Tier Nolan wrote:
> > The point is to have a single system that is compatible over a large
> > number of systems.
>
> There is such system and it is called BIP32.
>
> On the other hand, in BIP64 we try to put a
Pieter suggested in IRC couple of months ago to append key birth to key
serialization in xprv….@unixtime format.
What about picking this idea up in BIP64? It would greatly help the importing
client.
Regards,
Tamas Blummer
http://bitsofproof.com
signature.asc
Description: Message signed wit
On 04/23/2014 09:00 PM, Tier Nolan wrote:
> The point is to have a single system that is compatible over a large number
> of systems.
There is such system and it is called BIP32.
On the other hand, in BIP64 we try to put a set of restrictions and
rules on top of BIP32. There will always be some s
Using higher gap limit in the software is not prohibited, but then it
breaks the standard "as is", in mean that importing such wallet to another
BIP64 wallet won't recover the funds properly, without proper settings of
gap limit...
Gap limit 20 is the most sane defaults for majority of users (actu
I built such a merchant system handing out BIP32 addresses.
The gap size problem does not arise there since such a system has to have an
extra database keeping track of requests, so there is no added cost of storing
the key coordinates used by them. A scan is not needed the keys can be accessed
On Wed, Apr 23, 2014 at 7:46 PM, Pavol Rusnak wrote:
>
> > Setting the gap limit to high is just a small extra cost in that case.
>
> Not if you have 100 accounts on 10 different devices.
>
I meant for a merchant with a server that is handing out hundreds of
addresses.
The point is to have a si
The most useful meta data to optimize chain scan is the key birth date, then
the allowed gap size.
Tamas Blummer
http://bitsofproof.com
On 23.04.2014, at 20:39, Tier Nolan wrote:
> Different users could have different gap limit requirements. 20 seems very
> low as the default.
>
> A mercha
On 04/23/2014 08:39 PM, Tier Nolan wrote:
> A merchant could easily send 20 addresses in a row to customers and none of
> them bother to actually buy anything.
Such merchant would surely use some merchant system instead of generic
wallet software.
> Setting the gap limit to high is just a small e
Different users could have different gap limit requirements. 20 seems very
low as the default.
A merchant could easily send 20 addresses in a row to customers and none of
them bother to actually buy anything.
Setting the gap limit to high is just a small extra cost in that case.
Bip-32 serializ
For those who don't follow github pull requests regularly; there's pull
request for BIP64 defining HD wallet structure as discussed in this thread:
https://github.com/bitcoin/bips/pull/52
On Wed, Apr 23, 2014 at 8:01 PM, slush wrote:
>
>
>
> On Wed, Apr 23, 2014 at 7:42 PM, Pieter Wuille wrot
On Wed, Apr 23, 2014 at 7:42 PM, Pieter Wuille wrote:
>
> Storing the seed is superior to storing the master node already
> (whether coin specific or not), as it is smaller.
>
>
...Except that you're loosing flexibility (serialization, deserialization)
which gives you BIP32 node.
I see "bip32 seed
On Tue, Apr 8, 2014 at 5:41 PM, slush wrote:
> I've discussed the solution of "Litecoin seed" in BIP32 HMAC with Litecoin
> devs already, and after long discussion we've concluded that it is generally
> bad idea.
>
> When changing "Bitcoin seed" constant to something different, same *entropy*
> wi
On Tue, Apr 8, 2014 at 5:58 PM, Andreas Schildbach wrote:
> On 04/08/2014 05:46 PM, slush wrote:
>
> > It still doesn't mean that bitcoinj or Electrum cannot share the bare
> > minimum of BIP XX. Of course if somebody will use Electrum for 2to3
> > transactions and then move wallet to client which
On 04/08/2014 05:46 PM, slush wrote:
> I understand each client will implement things a little bit different,
> for example the current plan is bitcoinj will hold all keys in memory
> and start reusing keys on low resources. Electrum uses a chain for their
> private purpose. Etc.
>
On Tue, Apr 8, 2014 at 4:49 PM, Andreas Schildbach wrote:
> While there is an agreement that a standard would be useful for sharing
> wallets, we certainly didn't agree on every aspect of a standard. At
> least not on this thread, and also not at the Berlin meeting.
>
>
We're going to write down B
On Tue, Apr 8, 2014 at 3:53 PM, Pieter Wuille wrote:
> I see the cause of our disagreement now.
>
> You actually want to share a single BIP32 tree across different
> currency types, but do it in a way that guarantees that they never use
> the same keys.
>
> I would have expected that different cha
On 04/08/2014 02:43 PM, slush wrote:
> After some off-list discussion about details with wallet developers, it
> seems that structure
>
> m/'/'//
>
> fulfill requirements of all wallet developers around, including
> myTrezor, Electrum, Multibit, Wallet32 and other software is willing to
> adapt
On 04/08/2014 03:53 PM, Pieter Wuille wrote:
> Let me offer an alternative suggestion, which is compatible with the
> original default BIP32 structure:
> * You can use one seed across different chains, but the master nodes
> are separate.
> * To derive the master node from the seed, the key string
+1
I would prefer that solution...
Le 08/04/2014 15:53, Pieter Wuille a écrit :
> I see the cause of our disagreement now.
>
> You actually want to share a single BIP32 tree across different
> currency types, but do it in a way that guarantees that they never use
> the same keys.
>
> I would h
Pieter,
your suggestion has charm since “Bitcoin seed” would even not need
a global dictionary like the interpretation of the first level, since it would
be self describing.
Regards,
Tamas Blummer
http://bitsofproof.com
On 08.04.2014, at 15:53, Pieter Wuille wrote:
> I see the cause of our
I see the cause of our disagreement now.
You actually want to share a single BIP32 tree across different
currency types, but do it in a way that guarantees that they never use
the same keys.
I would have expected that different chains would use independent
chains, and have serializations encode w
tl;dr;
It is dangerous to expect that other seed than "xprv" does not contain
bitcoins or that "xprv" contains only bitcoins, because technically are
both situations possible. It is still safer to do the lookup; the magic
itself is ambiguous.
Marek
On Tue, Apr 8, 2014 at 3:40 PM, slush wrote:
On Tue, Apr 8, 2014 at 3:18 PM, Pieter Wuille wrote:
> I still don't understand the purpose of cointype. If you don't want to
> risk reusing the same keys across different currencies, just don't use
> the same seed or the same account? That is purely a client-side issue.
>
>
Of course it is purely
I still don't understand the purpose of cointype. If you don't want to
risk reusing the same keys across different currencies, just don't use
the same seed or the same account? That is purely a client-side issue.
If the consensus is to add the cointype anyway, can we fix it to be
equal to the 4-by
After some off-list discussion about details with wallet developers, it
seems that structure
m/'/'//
fulfill requirements of all wallet developers around, including myTrezor,
Electrum, Multibit, Wallet32 and other software is willing to adapt once
anything will be standardized (i.e. they don't ca
I agree that 'version' field of bip32 is not necessary and xpriv/xpub
should be enough for all cases; there's actually no need to use different
BIP32 roots for different altcoins.
I'm happily using one xpub for Bitcoin/Testnet/Litecoin at once, and by
having the "cointype" distinction in the bip32
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
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
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
1 - 100 of 107 matches
Mail list logo
