<div>Credit card transactions are simply an expample of a widely used payment system that has frequent fraud and chargebacks. The argument I&#39;m making is that different people in different situations value speed and convenience over a known fraud risk. Instant zero confirmation transactions are extremely useful despite the risk in all kinds of real world situations. You can&#39;t substitute your own value judgements for everyone in every situation.</div><div><br></div><div>Aaron</div><div><br><div class="gmail_quote"><div>On Thu, Jan 5, 2017 at 6:15 PM &lt;<a href="mailto:bfd@cock.lu">bfd@cock.lu</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">With a credit card you have an institution worth billions of dollars<br class="gmail_msg"><br>asserting that a payment has been made, with the option that it may be<br class="gmail_msg"><br>retracted under special circumstances by the card issuer.<br class="gmail_msg"><br><br class="gmail_msg"><br>Unconfirmed Bitcoin transactions with a SPV client has you trusting<br class="gmail_msg"><br>that the un-authenticated DNS seed lookup has not been tampered with,<br class="gmail_msg"><br>the connection to the random node that you connect to has not been<br class="gmail_msg"><br>tampered with, and that the seed nor the node are attempting to<br class="gmail_msg"><br>manipulate you.<br class="gmail_msg"><br><br class="gmail_msg"><br>The two scenarios aren’t even remotely comparable.<br class="gmail_msg"><br><br class="gmail_msg"><br><br class="gmail_msg"><br>On 2017-01-04 00:56, Aaron Voisine wrote:<br class="gmail_msg"><br>&gt; It&#39;s easy enough to mark a transaction as &quot;pending&quot;. People with bank<br class="gmail_msg"><br>&gt; accounts are familiar with the concept.<br class="gmail_msg"><br>&gt;<br class="gmail_msg"><br>&gt; Although the risk of accepting gossip information from multiple random<br class="gmail_msg"><br>&gt; peers, in the case where the sender does not control the receivers<br class="gmail_msg"><br>&gt; network is still minimal. Random node operators have no incentive to<br class="gmail_msg"><br>&gt; send fake transactions, and would need to control all the nodes a<br class="gmail_msg"><br>&gt; client connects to, and find a non-false-positive address belonging to<br class="gmail_msg"><br>&gt; the victims wallet.<br class="gmail_msg"><br>&gt;<br class="gmail_msg"><br>&gt; It&#39;s not impossible, but it&#39;s non trivial, would only temporarily show<br class="gmail_msg"><br>&gt; a pending transaction, and provide no benefit to the node operator.<br class="gmail_msg"><br>&gt; There are much juicier targets for an attacker with the ability to<br class="gmail_msg"><br>&gt; sybil attack the entire bitcoin p2p network.<br class="gmail_msg"><br>&gt;<br class="gmail_msg"><br>&gt; Aaron<br class="gmail_msg"><br>&gt;<br class="gmail_msg"><br>&gt; On Tue, Jan 3, 2017 at 11:47 PM Jonas Schnelli &lt;<a href="mailto:dev@jonasschnelli.ch" class="gmail_msg" target="_blank">dev@jonasschnelli.ch</a>&gt;<br class="gmail_msg"><br>&gt; wrote:<br class="gmail_msg"><br>&gt;<br class="gmail_msg"><br>&gt;&gt; Hi<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt;&gt; Unconfirmed transactions are incredibly important for real world<br class="gmail_msg"><br>&gt;&gt; use.<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt;&gt; Merchants for instance are willing to accept credit card payments<br class="gmail_msg"><br>&gt;&gt; of<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt;&gt; thousands of dollars and ship the goods despite the fact that the<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt;&gt; transaction can be reversed up to 60 days later. There is a very<br class="gmail_msg"><br>&gt;&gt; large<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt;&gt; cost to losing the ability to have instant transactions in many or<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt;&gt; even most situations. This cost is typically well above the fraud<br class="gmail_msg"><br>&gt;&gt; risk.<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt;&gt;<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt;&gt; It&#39;s important to recognize that bitcoin serves a wide variety of<br class="gmail_msg"><br>&gt;&gt; use<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt;&gt; cases with different profiles for time sensitivity and fraud risk.<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt;&gt;<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; I agree that unconfirmed transactions are incredibly important, but<br class="gmail_msg"><br>&gt;&gt; not<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; over SPV against random peers.<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; If you offer users/merchants a feature (SPV 0-conf against random<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; peers), that is fundamentally insecure, it will – sooner or later<br class="gmail_msg"><br>&gt;&gt; – lead<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; to some large scale fiasco, hurting Bitcoins reputation and trust<br class="gmail_msg"><br>&gt;&gt; from<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; merchants.<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; Merchants using and trusting 0-conf SPV transactions (retrieved from<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; random peers) is something we should **really eliminate** through<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; education and by offering different solution.<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; There are plenty, more sane options. If you can&#39;t run your own<br class="gmail_msg"><br>&gt;&gt; full-node<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; as a merchant (trivial), maybe co-use a wallet-service with<br class="gmail_msg"><br>&gt;&gt; centralized<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; verification (maybe use two of them), I guess Copay would be one of<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; those wallets (as an example). Use them in watch-only mode.<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; For end-users SPV software, I think it would be recommended to...<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; ... disable unconfirmed transactions during SPV against random peers<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; ... enable unconfirmed transactions when using SPV against a trusted<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; peer with preshared keys after BIP150<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; ... if unconfirmed transactions are disabled, show how it can be<br class="gmail_msg"><br>&gt;&gt; enabled<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; (how to run a full-node [in a box, etc.])<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; ... educate, inform users that a transaction with no confirmation<br class="gmail_msg"><br>&gt;&gt; can be<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; &quot;stopped&quot; or &quot;redirected&quot; any time, also inform about the risks<br class="gmail_msg"><br>&gt;&gt; during<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; low-conf phase (1-5).<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; I though see the point that it&#39;s nice to make use of the &quot;incoming<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; funds...&quot; feature in SPV wallets. But – for the sake of stability<br class="gmail_msg"><br>&gt;&gt; and<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; (risk-)scaling – we may want to recommend to scarify this feature<br class="gmail_msg"><br>&gt;&gt; and –<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; in the same turn – to use privacy-preserving BFD&#39;s.<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; &lt;/jonas&gt;<br class="gmail_msg"><br></blockquote></div></div>