On Wed, Mar 26, 2014 at 6:01 PM, Alan Reiner etothe...@gmail.com wrote:
This might be tangential, but the comment about refund chains reminded
me. Armory will be implementing multi-sig/linked wallets where a each
device has a parallel HDW branch and produces P2SH addresses. For those
types
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
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.
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
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
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 the same
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 idea, but
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 that
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 surprising
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
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
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
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,
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
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 that
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 stop
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
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
we
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:
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
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
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^128
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
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
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
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
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
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,
On Thu, Mar 27, 2014 at 5:21 PM, Pavol Rusnak st...@gk2.sk wrote:
Cointype in path is for separation purposes, not for identification.
I don't understand what that gains you.
--
Pieter
--
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
30 matches
Mail list logo
