Delivery-date: Sat, 06 Jul 2024 13:44:44 -0700 Received: from mail-yb1-f192.google.com ([209.85.219.192]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sQCGy-0003DF-BM for bitcoindev@gnusha.org; Sat, 06 Jul 2024 13:44:44 -0700 Received: by mail-yb1-f192.google.com with SMTP id 3f1490d57ef6-e03a92302d1sf4845057276.1 for ; Sat, 06 Jul 2024 13:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1720298678; x=1720903478; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=i3k+9/v6HRkaAutZzoxNXK7mQX7JPVXn8ROiya2o53E=; b=v9dF9bzAhohtrY1TY7ASaVffkbDxpFvjp338uUNfdB3pqu8X4JySu6NJsTdCjHXlhi TcHeN6MXYprtf6NPbj2TqAGoGMZj7pj3GNFYCTYTU8hs9BbiAxpxyuKlOowmiFiLapWo K5T+WdIEYsc2nOVjMaDwmZu3ozCBbcQlnUBazGJkMvlAf8ecY89yddgwB1UA6rewt+By tdFelb7wQNv+gscUH1vveBh4G1TVvDflQBJBKuUU9mzo9xlYtZZMKjwLt0w0AFkB3YTR neiu3nuS/We/NltR/gEbdF0j7Qyx+5oBJ9xzTLOt1SdiXtje2zQ4a9enaEG5PxjpGjnZ njHQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720298678; x=1720903478; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=i3k+9/v6HRkaAutZzoxNXK7mQX7JPVXn8ROiya2o53E=; b=aB2XHuASRqgGV/I7G+hiRSFQ9Nb07RKi9q75NsQrpx+hQfOSWdcgnDOrAa9P0DR28u pyhYmP+j8JUuFClDW3dbeytu6Dvu4FX6VFDa/01oAQ0zDWdzB/ZmQLI1QR7RxGYEJ8Rb wr6xK1oUtqrtzacPBThYYuI9UA8/ZGVoLgMiAcliK73sg/Flrmci9neGrEzsrHARDep6 krXkkpRgiSWCZUYdGjJP1dDimahlNGkIPLVthNptSooGGmA0MV+L6nfLG8Lz7AUJibm0 vKhHakcYds113tUDVdkNvdIZUraDDspF9OOIP9ViTASJ3YN3vFoA4vnP8ZubshHC/jmX EdEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720298678; x=1720903478; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=i3k+9/v6HRkaAutZzoxNXK7mQX7JPVXn8ROiya2o53E=; b=QzIC565L8SBDW1e1EHP0ucKUgI2/wNEWVcHunNgFsF89r6cdA8rol8ejuWcb1Ugilm hetcLWPZQI6bnIhVHhoJZFWqnPNmVcsRuphnv1BgXhXD99k3R6xRr8lqtzzkFpY/do54 8UTHQNRiAd3FpaX0ami+als23ZUFWK50zLYx2DFkDP/x1R/6H65Aac4/jH+6yiVuAAJl OgNUmtoNvwYGFsHtOZhyiHFg/PIueDoqoaSWvq2g0tAy1ZTORD3gv88lM9I8IXkOgF48 YWs+VZaszT0yJ3wplv/RaJJYeIXASmdHOz+9Cn5I2Lpdova4+TWg5mPhugp0UZIyS/mU wQGQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVTmcOnPm/AZtU1CuyqXQp2FYHn24QgbAMmOYw8d+Wl8RdvbWVF58pJkGP4mzWz7KUaavaVCIJwTeZue5gfzGxBxVvNtXw= X-Gm-Message-State: AOJu0YzBC/z55HFe/bi50YZe6xUSl8XtKoYUrD4Tx/dO8icFAVmBhLAv bAkfv8kzye4RpB3RNfVtplmGd1dLhute3gFoOkfBcpV6ewxPlXIF X-Google-Smtp-Source: AGHT+IEwMW1K0ikLkLpbgw3zD8nfwzr/1zhQaZUU3XuPpTfXTXtnnyJh22pUiBUfSQ4PPLExLyRHHA== X-Received: by 2002:a25:d0c3:0:b0:e03:60b4:1311 with SMTP id 3f1490d57ef6-e03c18f16cdmr8444353276.9.1720298677621; Sat, 06 Jul 2024 13:44:37 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6902:1205:b0:dff:aa9:b9ad with SMTP id 3f1490d57ef6-e03bd07819cls4334196276.2.-pod-prod-08-us; Sat, 06 Jul 2024 13:44:36 -0700 (PDT) X-Received: by 2002:a05:6902:154d:b0:de5:2694:45ba with SMTP id 3f1490d57ef6-e03c1649f30mr486467276.0.1720298676169; Sat, 06 Jul 2024 13:44:36 -0700 (PDT) Received: by 2002:a05:690c:2b8c:b0:64a:6fb4:b878 with SMTP id 00721157ae682-651456616b7ms7b3; Sat, 6 Jul 2024 13:41:43 -0700 (PDT) X-Received: by 2002:a81:9296:0:b0:62d:fbf:920a with SMTP id 00721157ae682-652d8531083mr805027b3.10.1720298502371; Sat, 06 Jul 2024 13:41:42 -0700 (PDT) Date: Sat, 6 Jul 2024 13:41:42 -0700 (PDT) From: Forrest96er To: Bitcoin Development Mailing List Message-Id: <72e1b8bf-11d0-4ee7-a18a-949d0e8acb16n@googlegroups.com> Subject: [bitcoindev] Idea for BIP : Deterministic Wallets with Token support MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_571092_1154064334.1720298502096" X-Original-Sender: abel.fricke@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_571092_1154064334.1720298502096 Content-Type: multipart/alternative; boundary="----=_Part_571093_1418156991.1720298502096" ------=_Part_571093_1418156991.1720298502096 Content-Type: text/plain; charset="UTF-8" Hello, The number of new tokens for Ethereum and Ethereum-like coins has increased dramatically. However, the wallet structure for managing multiple coins based on a single seed has not been updated to accommodate this new scenario. Currently, all tokens are managed using the same derivation path, resulting in the creation of identical addresses across different tokens, significantly reducing privacy. To address this issue, the wallet structure for HD wallets needs to be updated. Simply adding an additional node to the derivation path is not practical for various reasons. A better solution is to use the address or identifier of the token for creating private and public keys. This can be achieved by adding an additional input to the HMAC function, which is used to generate child private and public keys. It is advisable to apply a collision-free hash function before using HMAC. m / purpose' / coin_type' / account' / change / index I recommend applying the modification at the "Change" node. Without modification, the creation of an address for the base coin (no token) is targeted. With the modification, the token- adress is targeted. This approach also has the advantage that if hardware wallets are used, only the extended public keys of a coin need to be exported once to the front-end application. After that, the front-end application can generate all public keys needed to scan for transactions on all tokens. Even if a token did not exist at the time of the public key export, it could later be found without any additional export. Did I miss something? If an attacker obtains some public keys used in a transaction for a token, he should not be able to calculate the public keys of other tokens or the base coin. -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/72e1b8bf-11d0-4ee7-a18a-949d0e8acb16n%40googlegroups.com. ------=_Part_571093_1418156991.1720298502096 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello,

The number of new tokens for Ethereum and Ethereum-like coi= ns has increased dramatically. However, the wallet structure for managing m= ultiple coins based on a single seed has not been updated to accommodate th= is new scenario. Currently, all tokens are managed using the same derivatio= n path, resulting in the creation of identical addresses across different t= okens, significantly reducing privacy. To address this issue, the wallet st= ructure for HD wallets needs to be updated.

Simply adding an addition= al node to the derivation path is not practical for various reasons.

= A better solution is to use the address or identifier of the token for crea= ting private and public keys. This can be achieved by adding an additional = input to the HMAC function, which is used to generate child private and pub= lic keys. It is advisable to apply a collision-free hash function before us= ing HMAC.

m / purpose' / coin_type' / account' / change / index

I recommend applying the modification at the "Change" node. Without modifi= cation, the creation of an address for the base coin (no token) is targeted= .

With the modification, the token- adress is targeted.

This ap= proach also has the advantage that if hardware wallets are used, only the e= xtended public keys of a coin need to be exported once to the front-end app= lication. After that, the front-end application can generate all public key= s needed to scan for transactions on all tokens. Even if a token did not ex= ist at the time of the public key export, it could later be found without a= ny additional export.

=C2=A0 Did I miss something?
If an a= ttacker obtains some public keys used in a transaction for a token, he shou= ld not be able to calculate the public keys of other tokens or the base coi= n.=C2=A0=C2=A0

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/72e1b8bf-11d0-4ee7-a18a-949d0e8acb16n%40googlegroups.com.=
------=_Part_571093_1418156991.1720298502096-- ------=_Part_571092_1154064334.1720298502096--