This is not the place to discuss the merits and/or issues of these BIPs,
only whether they should be treated as final.
On Aug 25, 2016 10:51, "Marek Palatinus via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> As Luke pointed, BIP44 is already used by many wallets and to my
As Luke pointed, BIP44 is already used by many wallets and to my knowledge
people don't have any real world issues with that, including loading funds
in another BIP44 wallet. I'm not saying that BIP44 is perfect from all
points of view, but IMO it just works for most use cases. Let's set it as
> The development paradigm of "maybe detect funds" is not something we
> should *not* encourage for Bitcoin IMO.
Sorry. That was one "not" to many.
signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
Le 25/08/2016 à 09:39, Jonas Schnelli via bitcoin-dev a écrit :
> (I think this case if not completely unrealistic):
>
> What would happen, if a user gave out 21 addresses, then address0 had
> receive funds in +180 days after generation where address21 had receive
> funds immediately (all other
On Wednesday, August 24, 2016 1:47:08 PM Andreas Schildbach via bitcoin-dev
wrote:
> FWIW, BIP44 also doesn't encode a seed birthday. This needed so that SPV
> wallets do not need to scan from the beginning of the blockchain.
>
> That doesn't mean BIP44 could not be final. There are some wallets
On 24.08.2016 16:18, Jonas Schnelli via bitcoin-dev wrote:
>
> Another thing that I think could be a BIP misdesign:
>
> BIP44 Gap Limits
> From the BIP:
>
> --
> "Address gap limit is currently set to 20. If the software hits 20
> unused addresses in a row, it expects there are no
Hi
> 6 - Finally, and most importantly, BIP39 seed phrases do not have a
> version number. Without a version number, how are you going to derive
> addresses from a BIP39 seed phrase, when wallets start to use to new
> derivation methods (such as SegWit, or Schnorr signatures)? Does it mean
> that
FWIW, BIP44 also doesn't encode a seed birthday. This needed so that SPV
wallets do not need to scan from the beginning of the blockchain.
That doesn't mean BIP44 could not be final. There are some wallets that
interoperate on that standard and that's fine. The whole reason I
insisted on
Le 23/08/2016 à 22:12, Luke Dashjr via bitcoin-dev a écrit :
> BIP 39: Mnemonic code for generating deterministic keys
> - Used by many wallets and hundreds of thousands of users.
>
> BIP 44: Multi-Account Hierarchy for Deterministic Wallets
> - Appears to be implemented by multiple wallets.
>
On Tue, Aug 23, 2016 at 8:54 PM, Kenneth Heutmaker via bitcoin-dev
wrote:
> SPV is kinda broken if the wallet doesn’t do this detection. If your wallet
> connects only to nodes that don’t support bloom filtering, the wallet never
> gets updates. We have
>> Additionally, BIP 111 (NODE_BLOOM service bit) has been implemented in
>> Bitcoin
>> Core and derivatives; it is unclear if used by clients yet. Can developers of
>> such clients please comment and let me know: 1) if their software supports
>> this BIP already; 2) if not, do they intend to
> Additionally, BIP 111 (NODE_BLOOM service bit) has been implemented in Bitcoin
> Core and derivatives; it is unclear if used by clients yet. Can developers of
> such clients please comment and let me know: 1) if their software supports
> this BIP already; 2) if not, do they intend to support it
A number of BIPs seem ready for updating to Final Status. If there are no
objections, I will update these in 2 weeks:
BIP 39: Mnemonic code for generating deterministic keys
- Used by many wallets and hundreds of thousands of users.
BIP 44: Multi-Account Hierarchy for Deterministic Wallets
-
13 matches
Mail list logo