<div dir="ltr"><div class="gmail_quote"><div dir="ltr">I have pushed an updated version of the proposal which incorporates some of the received feedback and adds a note about the consequences of sharing a payment code-enabled walled on multiple devices:<br><br><a href="https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki" target="_blank">https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki</a><br><div><br></div><div><a href="https://github.com/justusranvier/rfc/commit/8c4d3429012eb15847c4ae68f212c8b2dcd1b521" target="_blank">https://github.com/justusranvier/rfc/commit/8c4d3429012eb15847c4ae68f212c8b2dcd1b521</a><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 25, 2015 at 12:21 AM, Justus Ranvier <span dir="ltr">&lt;<a href="mailto:justus.ranvier@monetas.net" target="_blank">justus.ranvier@monetas.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Fri, Apr 24, 2015 at 10:58 PM, Gregory Maxwell <span dir="ltr">&lt;<a href="mailto:gmaxwell@gmail.com" target="_blank">gmaxwell@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">So this requires making dust payments to a constantly reused address<br>
in order to (ab)use the blockchain as a messaging layer.<br>
<br>
Indeed, this is more SPV compatible; but it seems likely to me that<br>
_in practice_ it would almost completely undermine the privacy the<br>
idea hoped to provide; because you&#39;d have an observable linkage to a<br>
highly reused address.<br></blockquote><div><br></div></span><div>I agree that the output associated with notification transactions would require special handling to avoid privacy leaks. At a minimum they&#39;d require mixing or being donated to miners as a transaction fee.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
It would also more than double the data sent for the application where<br>
&#39;stealth addresses&#39; are most important: one-time anonymous donations<br>
(in other contexts; you have two way communication between the<br>
participants, and so you can just given them a one off address without<br>
singling in the public network.)<br></blockquote><div><br></div></span><div>Communication is only one way, except for the case in which the recipient wants to send a refund. Assuming no refund and only a single anonymous donation in the lifetime of the sender&#39;s identity, payment codes would require 65 bytes vs 40 bytes for stealth addresses.</div><div><br></div><div>As soon as the sender sends more than one donation to the same recipient, payment codes show an space advantage over stealth addresses.</div><span><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">This kind of binding was intentionally designed out of the stealth<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
address proposal;  I think this scheme can be made to work without any<br>
increase in size by reusing the payment code as the ephemeral public<br>
key (or actually being substantially smaller e.g. use the shared<br>
secret as the chain code, but I should give it more thought)<br></blockquote><div><br></div></span><div>With 97 byte standard OP_RETURN values the ephemeral public</div>key could be appended to the chain code, but that&#39;s undesirable for other reasons.<span><br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">This is fundamentally more expensive to compute; please don&#39;t specify<br>
&quot;uncompressed&quot;.<br></blockquote><div><br></div></span><div>Taking the SHA512 of something less than 512 bits seemed wrong.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">This appears incompatible with multisignature; which is unfortunate.<br></blockquote><div><br></div></span><div>I agree. I could not find a straightforward way to express a multisignature payment code in less than 80 bytes.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I&#39;m disappointed that there isn&#39;t any thought given to solving the<br>
scanning privacy without forcing non-private pure-overhead messaging<br>
transactions on heavily reused addresses. Are you aware of the IBE<br>
approach that allows someone to request a third party scan for them<br>
with block by block control over their delegation of scanning?<br></blockquote><div><br></div></span><div>I suspect this is a case where we just can&#39;t have all the features we want.</div><div><br></div><div>In this proposal I optimized for non-reliance on third party services and a guaranteed ability to recover spendable funds from a seed backup.<br><br>Gaining those two features resulted in some tradeoffs as you noted, but I think there are enough benefits to make them worthwhile.</div><div><br></div><div>In particular, payment codes could be the basis for a Heartbleed-free payment protocol that can positively identify customers and automatically provide refund capabilities in a merchant-customer relationship. A merchant only requires one payment code which they can safely use for all their customers, meaning they only ever need to associate 65 bytes with their identity to allow customers to make sure they are paying the right entity.<br><br>Exchanges could restrict bitcoin withdrawals to a single payment code known to be associated with their identified customer. This would make thefts easier (without involving address reuse as in locking withdrawals to a single P2PKH address).</div><div><br></div><div>In some jurisdictions the ability to prove that withdrawals are sent to a positively-identified party, rather than arbitrary third parties, might move some Bitcoin businesses out of money transmitter territory into less onerous regulatory situations.</div></div><br></div></div>
</blockquote></div><br></div>
</div></div></div><br></div>