samotari / paynoway

A mobile app for testing payment systems against double-spend attacks.
GNU General Public License v3.0
36 stars 8 forks source link

Implement techniques from petertodd/replace-by-fee-tools #44

Open emanuelb opened 3 years ago

emanuelb commented 3 years ago

The tool replace-by-fee-tools source-code at: https://github.com/petertodd/replace-by-fee-tools Contain several methods for double-spends

some links about above repo & more info: https://www.reddit.com/r/Bitcoin/comments/239bj1/doublespending_unconfirmed_transactions_is_a_lot/ https://www.coingecko.com/buzz/peter-todd-explains-how-he-double-spent-coinbase

this issue about implementing the techniques in above repo in this app.

chill117 commented 3 years ago

I'll quote some of the notable parts of the above links:

I could have taken advantage of the fact that some of the hashing power blocks payments to Satoshidice, the "correct horse battery staple" address, OP_RETURN, bare multisig addresses etc.

The double-spent tx has a few addresseses that are commonly blocked by miners, so it may have been rejected by the miner initially, or they may be using even higher fee rules. Or of course, they've adopted replace-by-fee.

Note that the work and posts by Peter Todd linked and quotes above are several years old. So some of it might not apply to today's bitcoin eco-system.

Some of the techniques mentioned rely on proprietary, internal rules set by miners. Usually a very opaque process - how miners include/exclude and order the transactions in their blocks. But still worthy of some experimentation if it can improve the reliability of double-spending - especially if it makes it possible to achieve non-RBF double-spends.

One thing to keep in mind about most of those techniques - it is necessary to add another output to the payment transaction. This will increase the absolute fee amount in sats. But this might not be such a bad thing because the double-spend transaction doesn't have to have a higher absolute fee, just a higher fee rate which is based on the size of the transaction in bytes. So if the extra output is dropped for the double-spend transaction, then the fee-rate will go up if the absolute fee stays the same.

emanuelb commented 2 years ago

Note that the work and posts by Peter Todd linked and quotes above are several years old. So some of it might not apply to today's bitcoin eco-system.

Tagging Peter Todd @petertodd as he can write more info on current situation of non-RBF double-spends attacks in bitcoin today (what's possible, more likely, etc...)

qoute from readme of petertodd/replace-by-fee-tools

In addition you can optionally specify that the first transaction additional OP-RETURN, multisig, and "blacklisted" address outputs. Some miners won't accept transactions with these output types; those miners will accept the second double-spend transaction, helping you achieve a succesful double-spend.

so this repo can have list of "blacklisted" addresses, and have option to try double spend with sending additional output to them (with warning that sending to such addresses is not recommended in general, but might work for double spending attacks)

also as both repos licenses is GPL-V3, coping is OK.

petertodd commented 2 years ago

Tagging Peter Todd @petertodd as he can write more info on current situation of non-RBF double-spends attacks in bitcoin today (what's possible, more likely, etc...)

Unfortunately I don't know what the current status is, as I haven't looked into it recently.

also as both repos licenses is GPL-V3, coping is OK.

Yup!