Why Nostr? What is Njump?
2023-06-07 02:12:21
in reply to

Stefan Thomas [ARCHIVE] on Nostr: 📅 Original date posted:2011-08-04 🗒️ Summary of this message: A pragmatic way ...

📅 Original date posted:2011-08-04
🗒️ Summary of this message: A pragmatic way to detect double spends is by connecting to multiple clients and checking if they all send the same transaction. A service like Transaction Radar can be used for this purpose. Network support for double spends may not be necessary and could be potentially damaging.
📝 Original message:Since nobody else has mentioned it: There is another (more pragmatic?)
way to detect double spends:

1. Connect to lots of clients
2a. If they all send you the same transaction -> double spend unlikely
2b. If some don't send you the transaction (or send a conflicting one)
-> double spend in progress

Obviously not everyone will run a double spend detector - it's much more
easily realized as a service (just like mining.) Jan put up a proof of
concept: http://www.transactionradar.com/

Would network support like a MSG_DOUBLESPEND be better? I used to think
yes, but looking at the reality of Transaction Radar, I'm not so sure.
Nothing stops such a service from scaling up and connecting to thousands
of random nodes (especially when the network itself grows bigger),
pushing the probabilities of missing a double spend "in the wild" to
near zero. It could also connect directly to important miners/pools as
others have suggested.

Of course this doesn't help against double spends where the attacker
does his own mining*, but neither would MSG_DOUBLESPEND. Given the added
network load I'd argue that network support for double spends is
unnecessary and potentially damaging. DoS is more scary to me than
non-instant transactions.

* In this case of course the hacker will be exposed to some randomness,
and I doubt many attackers will buy 100 televisions, newspaper
subscriptions or MP3s to get one for free. So this is only a problem for
liquid goods with tiny spreads (any investment or stored value instrument.)
Author Public Key
npub1f8c8h5evqyy29yp6p7jelyzw6vfwp6jz05exn66l4ygwkj57ytzqmap20e