Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1SQ6oe-0005DV-Nw for bitcoin-development@lists.sourceforge.net; Fri, 04 May 2012 00:56:14 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.175 as permitted sender) client-ip=209.85.216.175; envelope-from=etotheipi@gmail.com; helo=mail-qc0-f175.google.com; Received: from mail-qc0-f175.google.com ([209.85.216.175]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1SQ6od-00031S-VQ for bitcoin-development@lists.sourceforge.net; Fri, 04 May 2012 00:56:12 +0000 Received: by qcso7 with SMTP id o7so1922424qcs.34 for ; Thu, 03 May 2012 17:56:06 -0700 (PDT) Received: by 10.224.175.69 with SMTP id w5mr7203590qaz.49.1336092966516; Thu, 03 May 2012 17:56:06 -0700 (PDT) Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net. [76.111.96.126]) by mx.google.com with ESMTPS id hs1sm12007127qab.21.2012.05.03.17.56.05 (version=SSLv3 cipher=OTHER); Thu, 03 May 2012 17:56:05 -0700 (PDT) Message-ID: <4FA328CF.4020902@gmail.com> Date: Thu, 03 May 2012 20:54:39 -0400 From: Alan Reiner User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Wladimir References: <4FA2095D.9060307@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080306020708080602060002" X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (etotheipi[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1SQ6od-00031S-VQ Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] URI Handling in Bitcoin-Qt 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: Fri, 04 May 2012 00:56:14 -0000 This is a multi-part message in MIME format. --------------080306020708080602060002 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 05/03/2012 01:46 AM, Wladimir wrote: > > Label is a label for the destination address, message is a freeform > message describing the transaction. > > I don't think the message is currently stored in the Satoshi client. > That feature is somewhere on our way-too-long issue and todo list. > > But I understand that you want to add transaction meta-data fields > such as contact information, bought items, item prices? > > I don't want to add fields to the URI-spec, I just want to add them /to the client/. To me, it is ideal to have separate strings for labeling /addresses/ vs labeling /transactions/ -- i.e. different strings would show up in the address book (owner info) than what shows up in the transaction history (purchase info). I say it's ideal because that concept seems to fit perfectly with availability of "label=" and "message=" fields in BIP 21, but it won't actually work if Bitcoin-Qt won't/can't do it that way. For now, it seems that I should count on all important information being in the /label/ field, since users creating URLs would have to assume anything in the /message/ field will not be saved. Though I imagine the message data will be /displayed/ after the URI is clicked, just not saved. To expand the concept slightly further, it might make sense in the future for users to populate the /message/ and /label /fields with lots of data, using newlines. The first line would be used as a summary and displayed in the address book and ledger. The extra lines would all be displayed when the user opens up a details window. All of it would be automatically generated by the merchant, and the purchaser would end up with detailed documentation on every purchase they've made for zero effort. -Alan --------------080306020708080602060002 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 05/03/2012 01:46 AM, Wladimir wrote:

Label is a label for the destination address, message is a freeform message describing the transaction.

I don't think the message is currently stored in the Satoshi client. That feature is somewhere on our way-too-long issue and todo list.

But I understand that you want to add transaction meta-data fields such as contact information, bought items, item prices?



I don't want to add fields to the URI-spec, I just want to add them to the client.  To me, it is ideal to have separate strings for labeling addresses vs labeling transactions -- i.e. different strings would show up in the address book (owner info) than what shows up in the transaction history (purchase info).   I say it's ideal because that concept seems to fit perfectly with availability of "label=" and "message=" fields in BIP 21, but it won't actually work if Bitcoin-Qt won't/can't do it that way.

For now, it seems that I should count on all important information being in the label field, since users creating URLs would have to assume anything in the message field will not be saved.  Though I imagine the message data will be displayed after the URI is clicked, just not saved.

To expand the concept slightly further, it might make sense in the future for users to populate the message and label fields with lots of data, using newlines.  The first line would be used as a summary and displayed in the address book and ledger.  The extra lines would all be displayed when the user opens up a details window.  All of it would be automatically generated by the merchant, and the purchaser would end up with detailed documentation on every purchase they've made for zero effort.

-Alan

--------------080306020708080602060002--