Transaction

j"1LAnZuoQdcKCkpDBKQMCgziGMoPC4VQUckM<div class="post">SirArthur has a good point about the normal online merchant case, which is what the send-by-IP option is more suited to.&nbsp; This is the case where the merchant will have a server on a static IP and their own domain name and SSL cert.<br/><br/>Instead of connecting by IP, we can connect to a domain name by SSL, using the existing CA infrastructure to authenticate that you're connected to the owner of that domain.<br/><br/>The user would send to domain.com (or <a href="http://www.domain.com">www.domain.com</a> is ok too).&nbsp; That would be very natural and users could see and verify that what they entered is who they intend to pay.<br/><br/>The SSL also makes it safe for TOR users.<br/><br/>Problem is, I think merchants would still prefer to use bitcoin addresses to be certain they know what the payment is for.&nbsp; You simply cannot count on users to enter the right thing in the comment fields to identify the transaction.&nbsp; It would only approach practical if we had a mailto style link that prepopulates the comment field with the order number, but then the link could just as well be a bitcoin address. <br/><br/>Just having an open bitcoin server at domain.com that users could send unidentified payments to would be too much of a liability.&nbsp; Regular users aren't used to the idea of having to identify the payment.&nbsp; Merchants would get too many blank payments followed by "I paid you, where's my stuff?!" a week later.<br/><br/>The payment sequence does have a step where the receiver verifies the order before accepting it.&nbsp; It can reject the payment and return an error message if it doesn't contain a valid order number.&nbsp; That would require a difficult level of integration of custom code with the bitcoin server though.</div> text/html