On Thu, Aug 8, 2013 at 2:48 AM, Gavin Andresen <gavinandre...@gmail.com> wrote: > I've updated the BIP 72 spec at https://en.bitcoin.it/wiki/BIP_0072 so > the bitcoin address is optional: > > "If the "request" parameter is provided and backwards compatibility is > not required, then the bitcoin address portion of the URI may be > omitted (the URI will be of the form: bitcoin:?request=... )."
Sounds good. I'd still like to see some effort to avoid losing metadata and reducing the responsibilities of the sender. I see there's an implementation difficulty in avoiding to broadcast a transaction, but for example, if a payment_uri is specified, and it cannot be contacted (at all), the transaction should fail. As soon as you manage to connect, and have at least attempted to submit the transaction, the merchant may have received it, and you want to mark the coins spent, so store it after that point. But without such protection we'll likely see a unnecessary payments happening without metadata, when the payment server cannot be contacted for some reason. Also, the receiver most certainly needs a P2P implementation (and probably a strongly validating one) to verify incoming transactions, so having him broadcast it shouldn't be hard. I don't think the client should be required to stay online to broadcast at all, after a paymentACK is received. The transaction arrived safely at that point. -- Pieter ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
