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 BC97D3EE for ; Sun, 21 Oct 2018 21:54:39 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com [209.85.217.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 90DFA7C3 for ; Sun, 21 Oct 2018 21:54:38 +0000 (UTC) Received: by mail-vs1-f54.google.com with SMTP id i10so28359063vsm.13 for ; Sun, 21 Oct 2018 14:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=satoshilabs.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=uYUwtsp6EwNB3TpOS2e4u8AJdS4CVK14QOsaKNRaQ4U=; b=O0U4qZwQHtgsVISQ5UvlO+rZimuEQYEBnBE41u3hnS9cgXKWlebZ7ATXdDLs5os6BI Ytpar2o1uplPDdx+WezWiOsN7SISG/EiohXbSk+PHw9SsE3rROZCyUEjyYjFLPY9Nalo sSUvdZnMuHT54Jh6um/oC1f8Fi+hHVzPdPDDs+YxGKqEFLH9L7M2YcfCbFZwiYOmXtwQ wxAnwrjc6gIeWEJA/pw7BPwt2A6SHEbDFRCJnak3+lbWr0PV6lIll8cZ+1IYvG8bthxu dCkqmX1VcASNxEIj4KG5ZHLLo11UwHekRTOiP5OSI+39J9H3v8uNEGFe1lVWt0meB52c cIfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=uYUwtsp6EwNB3TpOS2e4u8AJdS4CVK14QOsaKNRaQ4U=; b=SPVBr72R+L5M+w2Iy/pUmaAC5D1C6f+nFfhjNWBF6/xhHEJvJSNbzaU352/YjrCg2N 7gLcvADi6RnwlGqN39UtvFSKbd7X1U8hyLEX6LVWBt13eq0t3iEydXdSRY/M62YhoLep DrS0WkM7lyrJrIFR2mNQt8NaHwtrU0UAKsHGLvvX+YFMGmG1m0njnmnRp44QfD25nG1P yDSvtQX8cJFebHYfi5dWwCasiSj9Roh207q1LoLu1gwL7WqnAMRQsV195hJBsse/YEqA RE0qc6V+yzIpC6q3tst973cEGOOGVgHVLs2YGkxX1c7KxnrCeSoTjcyvb5B+4IBgL0Hn lwgw== X-Gm-Message-State: ABuFfogmhko+AQVMS6OiH/7xZEfQr2TF675/VNh9RNL4ge82U+Xearjz Ac25JKVEedDm02VxdSPSqxNtr4g1xsrdvgKtLMu2Gw== X-Google-Smtp-Source: ACcGV60kQLLitI1Y9RtgYBbDME9PxAbGLHk8aFKYLJNRAqTK1JmK6eO/km1XuhSHxgpzroQrRymUwTmC0HZ7+rsHn6w= X-Received: by 2002:a67:86d5:: with SMTP id i204mr16753491vsd.169.1540158877595; Sun, 21 Oct 2018 14:54:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Pavol Rusnak Date: Sun, 21 Oct 2018 23:54:26 +0200 Message-ID: To: rhavar@protonmail.com, Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000cc16350578c42e2f" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, 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 X-Mailman-Approved-At: Mon, 22 Oct 2018 04:07:30 +0000 Subject: Re: [bitcoin-dev] Transaction Input/Output Sorting 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: Sun, 21 Oct 2018 21:54:39 -0000 --000000000000cc16350578c42e2f Content-Type: text/plain; charset="UTF-8" Your solution in the second part of the email does not solve the problem you indicated in the first part of your email. On Sun, Oct 21, 2018, 23:41 Ryan Havar via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Right now it's just *way* too easy to spot the boundaries between > different wallets. There's a lot of things that contribute to that, but the > one that concerns me the most is the way wallets sort transaction inputs > and outputs. > > Some wallets and protocols (especially HW wallets) have a strong > preference for deterministic sorting (i.e. using bip69), while other > wallets have a lot of objections to this. > > I'm not sure I fully understand the objections, but I think they can be > summarized as "during the transition period there will be a lot of privacy > loss" and "if in the future someone wants to use bitcoin in a way that's > not compatible with bip69 their transactions will stick out heavily". > > I wonder if this impasse could be solved with deterministic sorting, but > based on a semi-secret. Like `sortingSecret = hmac(walletSeed, > "sortingSecret")` and then there's a standardized sort order based on the > sortingSecret. e.g. sort inputs/output by the `hash(data || > sortingSecret)`. Wallets could come up with their own way of computing > (or storing) the "sortingSecret" but from there it's standardized. > > I has the advantages of deterministic sorting (as long as you know the > sortingSecret) you can verify it's done correctly and externally looks > totally randomized. > > Am I missing something, or could this be the way forward? > > -Ryan > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000cc16350578c42e2f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Your solution in the second part of the email does not so= lve the problem you indicated in the first part of your email.

On Sun, Oct 21, 2018, 23:41 Ryan H= avar via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Right now it's just *way* too easy to spot the bo= undaries between different wallets. There's a lot of things that contri= bute to that, but the one that concerns me the most is the way wallets sort= transaction inputs and outputs.

Some wallets and protocols (especially HW wallets) have a strong preference for deterministic= =C2=A0sorting (i.e. using bip69), while other wallets have a lot of objecti= ons to this.

I'm not sure I fully understand= the objections, but I think they can be summarized=C2=A0as "during th= e transition period there will be a lot of privacy loss" and "if = in the future someone wants to use bitcoin in a way that's not compatib= le with bip69 their transactions will stick out heavily".

I wonder if this impasse could be solved with determinis= tic=C2=A0sorting, but based on a semi-secret.=C2=A0 Like=C2=A0 `sortingSecr= et =3D hmac(walletSeed, "sortingSecret")` and then there's a = standardized sort order based on the sortingSecret. e.g. sort inputs/output= by the=C2=A0 `hash(data || sortingSecret)`.=C2=A0 =C2=A0Wallets could come= up with their own way of computing (or storing) the "sortingSecret&qu= ot; but from there it's standardized.

I has the advantages of deterministic sortin= g (as long as you know the sortingSecret) you can verify it's done corr= ectly and externally looks totally randomized.

Am I missing something, or could this be the way forward?
-Rya= n


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--000000000000cc16350578c42e2f--