I totally agree with gmaxwell here. The cost of interoperability is too
high. It would force us to freeze all features, and to require a broad
consensus everytime we want to add something new.
In addition, some partial level of compatibility would probably lead to
users not able to recover all
Maybe the solution is to have a defined way to import an unknown wallet?
This means that the gap space and a search ordering needs to be defined.
Given a blockchain and a root seed, it should be possible to find all the
addresses for that root seed.
The hierarchy that the wallet actually uses
Yes, it is expensive but possible to discover any funds associated with a seed,
provided there are set limits to:
1. gap of address use (e.g. 20)
2. depth of hierarchy (e.g. 6)
3. gap in use of parallel branches (e.g. 0)
I would pick the limits in brackets above.
Regards,
Tamas Blummer
Actually gap in parallel branches already fails with BIP64 as it starts with
m/64'/…. without having m/63'
Regards,
Tamas Blummer
http://bitsofproof.com
On 26.04.2014, at 12:59, Tamas Blummer ta...@bitsofproof.com wrote:
Yes, it is expensive but possible to discover any funds associated with
On 04/26/2014 12:48 PM, Tier Nolan wrote:
Maybe the solution is to have a defined way to import an unknown wallet?
That is nonsense. There is no way how to import the wallet if you don't
know its structure.
Given a blockchain and a root seed, it should be possible to find all the
addresses
On Sat, Apr 26, 2014 at 2:24 PM, Pavol Rusnak st...@gk2.sk wrote:
On 04/26/2014 12:48 PM, Tier Nolan wrote:
Maybe the solution is to have a defined way to import an unknown wallet?
That is nonsense. There is no way how to import the wallet if you don't
know its structure.
I agree. Especially
It is very young in bitcoin's life. We don't know what features will
work out best, or need to be radically changed after initial
deployment in the field.
Loose coordination is good. Good ideas will spread on their own.
Users will demand compatibility with certain features, and fail to
care
Does anyone use or plan to use the wallet structure part of the BIP32
document?
I suggest removing it from the document and maybe instead point at
BIP43. That new specification proposal just defines a purpose and
leaves everything else to the inventor of that purpose. The idea it that
over time a
Oh dear.
For reasons that are perfectly reasonable we are close to losing any chance of
intra-client HD compatibility for BIP32 wallets.
In the next 12 months there will probably be collectively millions of users of
our new wallets. I don't want them to suffer from vendor lockin.
Can we not
On Fri, Apr 25, 2014 at 7:53 AM, Jim jim...@fastmail.co.uk wrote:
Oh dear.
For reasons that are perfectly reasonable we are close to losing any chance
of intra-client HD compatibility for BIP32 wallets.
In the next 12 months there will probably be collectively millions of users
of our new
I generally agree, but I wonder how popular cloning wallets between devices
will be in future. Right now if someone wants to have a wallet shared
between Hive, blockchain.info and Bitcoin Wallet for Android, we just tell
them they're out of luck and they need to pick one, or split their funds up
On github I commented on the BIP43 pull request about adding a
purpose of 0' which would correspond to the BIP32 recommended tree
structure for a single account wallet. (m/0'/chain) This will allow
for backwards compatibility and interoperability at least for existing
single account BIP32
12 matches
Mail list logo
