From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z4l0r-0002ln-Bt for bitcoin-development@lists.sourceforge.net; Tue, 16 Jun 2015 07:10:25 +0000 Received: from mail-wi0-f171.google.com ([209.85.212.171]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z4l0p-0001Xa-4r for bitcoin-development@lists.sourceforge.net; Tue, 16 Jun 2015 07:10:25 +0000 Received: by wifx6 with SMTP id x6so9850456wif.0 for ; Tue, 16 Jun 2015 00:10:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gJdhVHPL7tyBadiDYOe+gKAX/oQ9oRb7xjEhLlAHixg=; b=VCQtpK22SSnZl7uMunbMYOENsxGXftWEkEBSUo10vIiq1E5qwivnnF9EuJvdGyxPZ5 mWdrZTY7xaevV07i6M8wjmUlvZbk9X3NwSmzVeo2bRu2xZQhMz6wH8QGUjh/u5QPPuBI PcqrQF6yP8Hlt3uTtebGlNAlMZQ7iPHMLePFkasg7GReKRN0Qcm6bHryt9WSiM0iQMRW e1BP8TgNarfCPkDWP3LEENvM94N/nc5zhM7gLp27BPsxZ4OnVSNL9Q3b7RVdnlE5Y3i1 u/qcww5ej+5KuLSnh3lFJgMRfN2i2UpeY7kSbaGLzT99IYLvhRxfQAFbaXScK9al8d7i WrKw== X-Gm-Message-State: ALoCoQnup1jzSpu5dJasalEkrq9Qt/LLkBdavfd9uFvSQlNDqLfljVX20SmVhVv5ZcIyVAcqEJpk MIME-Version: 1.0 X-Received: by 10.180.149.240 with SMTP id ud16mr39699470wib.7.1434438617137; Tue, 16 Jun 2015 00:10:17 -0700 (PDT) Received: by 10.194.139.235 with HTTP; Tue, 16 Jun 2015 00:10:17 -0700 (PDT) Received: by 10.194.139.235 with HTTP; Tue, 16 Jun 2015 00:10:17 -0700 (PDT) In-Reply-To: <87eglcelf3.fsf@rustcorp.com.au> References: <87k2vhfnx9.fsf@rustcorp.com.au> <87r3pdembs.fsf@rustcorp.com.au> <87eglcelf3.fsf@rustcorp.com.au> Date: Tue, 16 Jun 2015 09:10:17 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Rusty Russell Content-Type: multipart/alternative; boundary=001a11c260e23a1d1205189d4484 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1Z4l0p-0001Xa-4r Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 07:10:25 -0000 --001a11c260e23a1d1205189d4484 Content-Type: text/plain; charset=UTF-8 On Jun 15, 2015 11:43 PM, "Rusty Russell" wrote: > Though Peter Todd's more general best-effort language might make more > sense. It's not like you can hide an OP_RETURN transaction to make it > look like something else, so that transaction not going to be > distinguished by non-canonical ordering. What about commitments that don't use op_return (ie pay2contract commitments)? In any case, if the motivation is ordering in multi-party transactions there should be ways to do it without any consequences for other transaction types' privacy. For example you could have a deterministic method that depends on a random seed all parties in the transaction previously share. That way the ordering is deterministic for all parties involved in the transaction (which can use whatever channel they're using to send the parts to also send this random seed) while at the same time the order looks random (or at least not cannonical in a recognisable way) to everyone else. --001a11c260e23a1d1205189d4484 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jun 15, 2015 11:43 PM, "Rusty Russell" <rusty@rustcorp.com.au> wrote:

> Though Peter Todd's more general best-effort langua= ge might make more
> sense.=C2=A0 It's not like you can hide an OP_RETURN transaction t= o make it
> look like something else, so that transaction not going to be
> distinguished by non-canonical ordering.

What about commitments that don't use op_return (ie pay2= contract commitments)?

In any case, if the motivation is ordering in multi-party tr= ansactions there should be ways to do it without any consequences for other= transaction types' privacy. For example you could have a deterministic= method that depends on a random seed all parties in the transaction previo= usly share. That way the ordering is deterministic for all parties involved= in the transaction (which can use whatever channel they're using to se= nd the parts to also send this random seed) while at the same time the orde= r looks random (or at least not cannonical in a recognisable way) to everyo= ne else.

--001a11c260e23a1d1205189d4484--