<div dir="ltr"><div>It&#39;s neat to use the payment address as an implicit signature by hashing 
something and multiplying it into the payee&#39;s pubKey.</div><div><br></div>
<div> </div>
<div>One downside is that it complicates the merchant&#39;s wallet.  In this case the payment is going to a pseudo-random address which 
the merchant will have to explicitly add to their wallet, complicating backups, etc.</div><div><br></div>
<div> </div>
<div>The other challenge is how to handle an error when you POST to the 
payment_url.  In the original spec, the payer would only broadcast the 
transaction themselves if there wasn&#39;t a payment_url.  In the current version it 
looks like the payer will broadcast the transaction(s) either way. I only saw 
some of the discussions around this, but I think part of the problem is what 
state do you put the payer&#39;s wallet into if you POST a Payment and don&#39;t get a 
PaymentAck?  If the payer always broadcasts the transaction, then wallet state 
becomes obvious. With your proposal you would not want the payer to broadcast 
the transaction without a PaymentAck, since you need the merchant to acknowledge 
they know where to look for the payment.</div><div><br></div>
<div> </div>
<div>Backing up a step, I&#39;m not sure what the threat model is for signing the 
refund address? The same process that&#39;s signing the transaction is doing an 
HTTPS POST with the refund address. If an attacker can defeat that, then they 
can just redirect the payment in the first place. The only benefit I can think 
of is the payer can prove what refund address they specified with the 
payment.</div><div><br></div>
<div> </div>
<div>Wouldn&#39;t it be easier to just get the merchant to sign the PaymentAck? 
Technically they already are signing it, but a TLS stream probably isn&#39;t the 
most convenient way to capture that.</div></div>