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