Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TkQIH-0002pu-Df for bitcoin-development@lists.sourceforge.net; Mon, 17 Dec 2012 02:19:01 +0000 X-ACL-Warn: Received: from mail-pb0-f47.google.com ([209.85.160.47]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1TkQIG-0005ui-0w for bitcoin-development@lists.sourceforge.net; Mon, 17 Dec 2012 02:19:01 +0000 Received: by mail-pb0-f47.google.com with SMTP id un1so3263770pbc.34 for ; Sun, 16 Dec 2012 18:18:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=kGSfbCcheqxIYjkzTjrkwt7k6q+prCgFqm9+rhevlqo=; b=OxSys7mo3EHLnkPFH2WY2NCcAJODAXNShV/YdU8lepaYTlqY0hYpWJa0CiU8zvqG8H FvOraYfHlAw01rhtQw5G8SeUNRKaXi+SCfubOcTKxlW1579CzjzIY5FFgkumn+a2/DOo u6Sc6DlZiJbLtHIGyoTEN2NRjPZovNYmDRGfD+XSt/TEAIZjT/oNFjx+CA9RKqMbzg66 1VOBlnoQ1uXi/OFbnURAHcrHn2/7Fda2RjJB1vB/kxp8lQu95dMVcEujKHZXM+SvVIns 2pMd+rX1ToYS1YzuzSCwbJY5bU+Kx5zHq/1xnns9PF+f0jBGqiKailBBXUVKf1IEYqEG S4Hg== MIME-Version: 1.0 Received: by 10.66.77.38 with SMTP id p6mr38094012paw.47.1355710734235; Sun, 16 Dec 2012 18:18:54 -0800 (PST) Received: by 10.69.0.196 with HTTP; Sun, 16 Dec 2012 18:18:54 -0800 (PST) X-Originating-IP: [2001:4830:1603:2:21c:c0ff:fe79:c8c2] In-Reply-To: References: <20121128233619.GA6368@giles.gnomon.org.uk> <20121129170713.GD6368@giles.gnomon.org.uk> <20121129185330.GE6368@giles.gnomon.org.uk> Date: Sun, 16 Dec 2012 21:18:54 -0500 Message-ID: From: Jeff Garzik To: Melvin Carvalho Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmXpjHuDHgVU+lf+aDOp9VnuSqJlh0hhXn2Hj9FBTi+4YOCft0OBuEzyNWMZypsgFqDdqZs X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1TkQIG-0005ui-0w Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts 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: Mon, 17 Dec 2012 02:19:01 -0000 On Sun, Dec 16, 2012 at 4:15 PM, Melvin Carvalho wrote: > On 3 December 2012 20:35, Mike Koss wrote: >> It would also be really nice to migrate to textual representations of data >> structures as opposed to binary ones. The most successful internet >> standards are based on text, making them that much more accessible for >> developers to deal with them. JSON would be my preferred candidate. >> >> Why don't we sign the text representation of a (utf8) JSON, rather than >> some complex encoding standard of JSON? That way the signatures are simple >> - and you need only retain the original textual representation of a message >> to validate the signature (as well as the decoded version, if you don't want >> to alway re-parse the message when writing programs that use it). > Binary formats can be challenging to deal with and convert to other formats. > The experiences in the PKI world of ASN.1 have not been great, in terms of > interop. It tends to create islands and silos. This is probably one of the > reasons why X.509 and GPG are fragmented and why we dont really have a > widely deployed web of trust on the net. Another reason is simply lack of > developer resources to make tools. In that respect I think JSON offers > significant advantages, though I am interested in the security issues > raised. I thought this had already been covered up-thread? When creating something that must be hashed and/or compared, the data structure must be created and reproduced precisely, byte-for-byte. JSON offers significant -disadvantages- in this regard. With JSON, you would therefore require an additional middle layer, between JSON and application, ensuring that all fields are output in the same order, all whitespace is not only perfectly preserved -- but reliably generates identical whitespace output for identical inputs, given two separate JSON implementations. -- Jeff Garzik exMULTI, Inc. jgarzik@exmulti.com