Timeline for How to minimize risk when accepting zero confirmation payments?
Current License: CC BY-SA 3.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 16, 2020 at 11:10 | history | edited | CommunityBot |
Commonmark migration
|
|
| Aug 29, 2015 at 11:04 | comment | added | jangorecki | This answer should definitely link/mention the Have a Snack, Pay with Bitcoins document, google it | |
| Oct 8, 2014 at 0:25 | comment | added | Chris Martin | It's important to note that Coinbase only gives you double-spend protection if you're using their paid "instant-exchange" service which immediately cashes out payments for fiat. If you're keeping the bitcoin in your Coinbase wallet, no such guarantee is provided. (Their documentation is not entirely clear on this, but I just got this clarification from a Coinbase support rep.) | |
| May 24, 2014 at 7:02 | comment | added | Pacerier | @JoeAmenta, Good idea on "dynamic fees" there. | |
| May 24, 2014 at 0:08 | comment | added | Joe Amenta | @Pacerier, the third-party has a bunch of options at high volume, so long as it's not killing their business. If that party observes that an average 1% of all transacted volume is lost to double-spends, then they can start charging a flat 1% fee to recoup the losses. If a particular merchant proves to be problematic, then they can simply drop that merchant (or charge a higher fee if it's just the nature of the merchant's business). | |
| May 23, 2014 at 16:30 | comment | added | Pacerier | @JoeAmenta, But delegating the task to a 3rd party is simply pushing the problem around the table. The question is still valid: How does the 3rd party minimize risk when he accepts zero confirmation payments? | |
| Apr 28, 2014 at 9:20 | comment | added | Joe Amenta | let us continue this discussion in chat | |
| Apr 28, 2014 at 9:19 | comment | added | Joe Amenta | That raises a good point. While pools generally act as just "one big miner" for most purposes, that's not necessarily true when it comes to keeping a particular transaction a secret. Without having looked into these protocols in too much detail, you can easily hide a transaction in the data used for stratum or the increasingly obsolete getwork protocols, but with getblocktemplate, it should be impossible for the pool to do this in secret (though individual miners can do this on their own) | |
| Apr 27, 2014 at 19:51 | comment | added | RocketNuts | Sure, but that would only apply to individual miners, right? Which generally have a very small chance of actually mining the next block, in which they're trying to include a secret tx (at the expense of a public tx not getting confirmed). But when checking the transaction data that is being mined by pools, I'd say this should be detectable...? Or is there a way to do pooled or distributed mining (i.e. have many people simultaneously trying to hash a list of transactions, including a secret tx) without actually disclosing the secret tx? | |
| Apr 27, 2014 at 19:26 | comment | added | Joe Amenta | Not really. If miners are incentivized to secretly favor some transactions over others, then they have no reason to share that information with anyone other than the person who contracted them to include the double-spend transaction. Even if they did, you would have no reason to trust them. | |
| Apr 27, 2014 at 18:47 | comment | added | RocketNuts | Would it be feasible to connect to such mining pools (or all major mining pools for that matter), just to see what transactions are supposed to be included? | |
| Apr 27, 2014 at 16:35 | comment | added | Joe Amenta | That's an important distinction to make, and it's subtle. Yes, miners are typically running "normal" nodes, but remember that miners only typically do things to help the network because it furthers their own self-interest. If you have an arrangement with miners to pay them some cut of your double-spend gains, then it's to their advantage to keep your transactions secret until they hit the blockchain. They control the software that they're running, and it's open-source. Heck, miners already run modified node software. Eligius implements CPFP, which isn't in standard node software. | |
| Apr 27, 2014 at 16:15 | comment | added | RocketNuts | Thanks for the detailed answer. Are miners typically not normal nodes in the sense that they don't relay or propagate transactions to the rest of the network? I mean if I would deliberately send a 'secret' tx to a miner's node (hoping to get that included in the blockchain), wouldn't it get relayed to other nodes as well, thus allowing its presence to be detected on the network? | |
| Apr 27, 2014 at 16:12 | vote | accept | RocketNuts | ||
| Apr 27, 2014 at 15:51 | history | edited | Joe Amenta | CC BY-SA 3.0 |
Realized you specifically called out Coinbase etc., so adjusted the last paragraph accordingly.
|
| Apr 27, 2014 at 15:36 | history | answered | Joe Amenta | CC BY-SA 3.0 |