public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: rhavar@protonmail.com
To: Pavol Rusnak <stick@satoshilabs.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Transaction Input/Output Sorting
Date: Mon, 22 Oct 2018 01:54:55 +0000	[thread overview]
Message-ID: <oTVax1iu2AHkNx8jQ9QlnWr2FS6Uusm1zKPZOkn1XRBv5my23NvVab0lWWH3DSbt3pXEv-ZsmhhU79MGuwnUdP2EKMk931XRyvuLxPRMyjk=@protonmail.com> (raw)
In-Reply-To: <CAF90Avnbxd3HA0yPcr929sf0o7ihF3SgcnCfqbvAeA8uxZa4Og@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2661 bytes --]

On Sunday, October 21, 2018 2:54 PM, Pavol Rusnak <stick@satoshilabs.com> wrote:

> Your solution in the second part of the email does not solve the problem you indicated in the first part of your email.

Sorry, I'm not quite sure what parts you are referring to. I assume you might mean my first paragraph, so I'll try explain myself a bit clearer how this makes it harder to find wallet boundaries.

Right now you can generally tell if a transaction is using bip69 or not (as long as you account for the probability that it's randomly sorted to accidentally be bip69). And generally wallets are consistent if they use bip69 or not.

This can often make it massively easier to detect what is change and not. Let's say I'm clustering a wallet and know they're using a wallet that always uses bip69, and I'm looking at a transaction in that cluster and trying to guess which is the change and which is not. There's a lot of things you can use to assign a probability. The most obvious thing is looking at the amount of significant-digits of the output amounts  (if they vary a lot, change tends to be the one with more), but a much more powerful one is looking at how the outputs are spent (and if they end up spend-linking back into the original cluster).

So let's say that the transaction output is spent by a non-bip69 transaction -- I right away know that it's going to (almost certainly) be a different wallet (e.g. the destination).

My  (shower-thoughty) "solution" fixes this problem, because an outside observer has no way of knowing if a transaction is using deterministic sorting or not, so can not use this information to establish wallet boundaries.

--
On somewhat of a tangent I was actually fortunate enough to have someone with access to the biggest(?) bitcoin analysis service help me with a few experiments. While I was genuinely taken aback by how accurate some of their analysis can be, I also found it pretty easy to trick -- implying it relies heavily on some fragile heuristics.

I don't like to be alarmist, but I worry a lot about the fungibility of bitcoin when we have such effective blockchain analysis and a *LOT* of the ecosystem using a centralized analytics service. And in fact, we're already starting to see some minor effects of this (e.g. people already know that if they gamble their funds, they'll probably have trouble using an exchange later). And I don't think we're too far from the point where any "unidentified" bitcoin is instantly flagged as "suspicious" (and for instance, requires more explaining for by exchanges) potentially seriously harming bitcoin fungibility and it's value determined also by it's history.

[-- Attachment #2: Type: text/html, Size: 2979 bytes --]

  reply	other threads:[~2018-10-22  1:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-21 19:00 [bitcoin-dev] Transaction Input/Output Sorting rhavar
2018-10-21 21:54 ` Pavol Rusnak
2018-10-22  1:54   ` rhavar [this message]
2018-10-23 14:29     ` Chris Belcher
2018-10-24 16:12       ` Gregory Maxwell
2018-10-24 17:52         ` rhavar
2018-10-24 18:21           ` rhavar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='oTVax1iu2AHkNx8jQ9QlnWr2FS6Uusm1zKPZOkn1XRBv5my23NvVab0lWWH3DSbt3pXEv-ZsmhhU79MGuwnUdP2EKMk931XRyvuLxPRMyjk=@protonmail.com' \
    --to=rhavar@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=stick@satoshilabs.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox