From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 736701132 for ; Wed, 30 May 2018 14:08:11 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f170.google.com (mail-ua0-f170.google.com [209.85.217.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 49C2314B for ; Wed, 30 May 2018 14:08:10 +0000 (UTC) Received: by mail-ua0-f170.google.com with SMTP id d4-v6so12549118ual.10 for ; Wed, 30 May 2018 07:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=qcb7MGzko99iJwBvYZnoPu/o90e1UKqch66XZjZJv/4=; b=YLpuekZBHXGvKGzmaao2WyDKJhM+noPGCVRrxjzp3KGwNN9n9Eh3bOwsFdWuo8A2By 6VltOis4gQDE57JpP0tjE4NvpSOwVDkjDiTXpt5LJeRKtXWexO41yk8yj2O3snsdOGYM AhnL7bend0ypifk5pptTPm4kW8dJ4u4HeFLUeY6VMju63QiucLdkozLocjCCq9utO8s7 86GpO+xvC21g8iv79KJB2wiZYAdn5S0h2Yxie0l3FvzcoBT53UZW12b428zyVkfWZ0HE 5tj3vKIJz6oYLWL1+1J2nNqoY37D+JvbVhXgJ2hlM8fMQBPFUFLaKltBouVxYBz17s6W VAMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=qcb7MGzko99iJwBvYZnoPu/o90e1UKqch66XZjZJv/4=; b=IKeiqURNBIVrpyJJzySPCWqP4fw7t4iK5B5MVyeQPczye939z1x1ozsKx9lC9lXIbV Asq3dGht533oIBtE1keCLi2RlB+Kx0fj75qcEclLmw81ruYCVv4rm63sd00Btqz60WYA 7u3xP/9pNWryZm0wKgtIXmbAmlvcSUEEn6Yqbvg4/B7R/RdStSjv0VIsSuQ0nTJyhsDc IdkjhwZhPGM0DdIZrgYdA776pYkz4WigFSag8olBqjHx5rJEH6qtSxCVJZNjCgRJ9eok fkEKhohM8r7GU2+rNlG3nlRHY2Ql1uygAfVbPN9zx87W9pdBRNjKpJPjJE2pEgL4bKfZ +OMw== X-Gm-Message-State: ALKqPwegRgSa9lavFFL0qtQDALv++m+apG82p4eH3wnGT9B3vkAAjmhZ 1QkSmosE4hkCyDuS8y1m7Rs2bwNxYU4HVK1n6RI= X-Google-Smtp-Source: ADUXVKIP55r324PuQH3/JS0xr2SA2VFIVmIRcSLs1VH4p4nuas+uz/S7xnhjJGmSSfG9bYxN4BttWL1R0YpVxR4+qkU= X-Received: by 2002:ab0:18ee:: with SMTP id d46-v6mr1797968uah.39.1527689289423; Wed, 30 May 2018 07:08:09 -0700 (PDT) MIME-Version: 1.0 Sender: gmaxwell@gmail.com Received: by 2002:a67:5193:0:0:0:0:0 with HTTP; Wed, 30 May 2018 07:08:08 -0700 (PDT) In-Reply-To: References: From: Gregory Maxwell Date: Wed, 30 May 2018 14:08:08 +0000 X-Google-Sender-Auth: 3ZicazhVanDEBKUfXa3AHkz_p04 Message-ID: To: shiva sitamraju , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] New serialization/encoding format for key material X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 14:08:11 -0000 On Wed, May 30, 2018 at 6:30 AM, shiva sitamraju via bitcoin-dev wrote: > The idea to add birthdate and gap limit sounds very good and addresses lots > of problems users are facing. > > However, adding birthday to keys breaks two basic properties > > - Visually Comparing two keys to find if they are same (Important) Can you explain exactly what you mean there? I can think of to plausible meanings (that two valid keys could differ by only a single symbol, which wouldn't be true due to the checksum and could be made even stronger if we thought that would be useful or I think you could also be complaining that the same "key material" could be encoded two ways which I think is both harmless and unavoidable for anything versioned). > - Different wallet software could set different birthday/gap limit. creating > different xpub/xprv for the same set of mathematically derived individual > keys. This removes the decoupling between key and wallet metadata Personally, I think it's a mistake to believe that any key format can really make private keying material strongly compatible between wallets. At best you can hope for a mostly compatible kind of recovery handling. But the lookahead amount may be pretty integral to the design of the software, so signaling it may not mean the other side can obey the signal... but that wouldn't make the signal completely useless.