Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VBXjU-0001Td-HX for bitcoin-development@lists.sourceforge.net; Mon, 19 Aug 2013 22:15:28 +0000 X-ACL-Warn: Received: from petersson.at ([213.239.210.117]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1VBXjT-0003Su-5L for bitcoin-development@lists.sourceforge.net; Mon, 19 Aug 2013 22:15:28 +0000 Received: by petersson.at (Postfix, from userid 65534) id A3C4D19A063; Tue, 20 Aug 2013 00:15:20 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on petersson.at X-Spam-Level: X-Spam-Status: No, score=-1.0 required=4.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.1 Received: from [192.168.0.199] (chello084114039092.14.vie.surfer.at [84.114.39.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: andreas) by petersson.at (Postfix) with ESMTPSA id 5FCE119A063 for ; Tue, 20 Aug 2013 00:15:20 +0200 (CEST) Message-ID: <521298F0.20108@petersson.at> Date: Tue, 20 Aug 2013 00:15:12 +0200 From: Andreas Petersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -2.8 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1VBXjT-0003Su-5L Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72 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, 19 Aug 2013 22:15:28 -0000 I was just reviewing the integration work to integrate the Payment Protocol into our products. Is there any notion of a standardized invoice serialisation? If i pay for two Burgers and one Club Mate, how would my Bitcoin Wallet be able to know that? Right now, i would simply put that into "memo" and come up with my own serialisation mechanism. Second, is there a way to communicate acceptance levels of TX (unconfirmed, 1 conf, 6 conf) maybe using several PaymentACK? -Andreas