Bitcoin Forum
October 03, 2025, 10:43:49 AM *
News: Latest Bitcoin Core release: 29.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Development & Technical Discussion / Re: How to minimize risk when accepting zero confirmation payments? on: May 21, 2014, 07:53:50 PM
I believe the paper you meant is "Have a Snack, Pay with Bitcoins" 

http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf
2  Bitcoin / Development & Technical Discussion / Re: How to minimize risk when accepting zero confirmation payments? on: May 21, 2014, 06:08:20 PM
Yes, I'm interested in a "good guys" service that deploys a network of neutral nodes that would, among regular activities of an upstanding node, sniff for double spends (I mean unconfirmed txns that spend the same inputs). If that network distributes nodes effectively across the graph, it would make it very difficult for an attacker to hide a double spend txn from the merchant node to which he sent the deceptive original txn. The merchant could check with that network before committing to the original txn. This form of validation could transpire in seconds and afford something like the same level of protection as waiting ~10min for the 1st block confirm.

And why not call it Palantir to make sure everyone knows a nerd thought of it?
3  Bitcoin / Development & Technical Discussion / Re: How to minimize risk when accepting zero confirmation payments? on: May 11, 2014, 08:50:31 PM
Has anyone done empirical analysis to determine the probability of a failed transaction after a given number of confirmations?

More specifically:
    If my transaction has 0 confirms (i.e. not in a block yet), what is the chance if will eventually fail to fully confirm?
    If my transaction has 1 confirm (i.e. in exactly 1 block so far), what is the chance if will eventually fail to fully confirm?
    And so on ...

I believe this cannot be done directly from the blockchain, as a failed transaction is not in the blockchain (?). I thnk you need to look at all transactions, failed or fully confirmed.

Does it boil down to noting which transactions belonged to forks which did not prevail and are not in the prevailing fork?

My interest here is really an empirical or numerical analysis. I am not looking for the model approach, nor is opinion, erudite or otherwise, gonna do the trick. Just how often it has happened.

Thanks!
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!