Topic: Fake Transaction Input (Read 442 times)

Nope, minimally equivalent to the minrelaytxfee that the nodes are using. Currently, by default reference implementation uses 1sat/vbyte as the mintxrelayfee rate. Hence, assuming that the majority of the nodes are adopting this, you need to at least pay an extra 1sat/vbyte for the RBF to work.

Note that this assumes that none of the parameters are changed and only guarantees good propagation. The miners are able to define their own parameters to allow for RBF.

How big is this minimum? May I add extra 0.01 SAT/vByte to replace an old transaction with a new one?

I tested it and it will only work with minrelaytxfee=0
Seems like the relay setting affects the owner's mempool as well.

Otherwise, with the default relay settings, it will return with: min relay fee not met, 0 < vsize (code -26)

Perhaps you could do it with Bitcoin Core. On the sending wallet's node, create a raw transaction with a fee of 0 using createrawtransaction and signrawtransactionwithkey. Enter the transaction on both the sending and receiving wallet nodes using sendrawtransaction so that they both see it. I assume the transaction will be added to their mempools because they are valid, but will not be relayed because the fee is too low.

I have never tried it, so I don't know if it will work.

Correct. If the input is invalid, then the transaction is invalid and it will be rejected by EVERY node on the network.


Broadcast it to whom? Bitcoin nodes will simply reject it.


It is exactly zero.  Invalid transacitons can not be confirmed.


No. That is incorrect. Fake, invalid, transactions never get into the mempool in the first place.  A transaction is verified BEFORE it is accepted into the mempool.


How would a wallet or an exchange know that you created a fake transaction? Why would they care?

As Pmalek said sophisticated / competent place is not going to allow for withdraw till it clears. Even more so if you have RBF enabled.
This would only be useful for a P2P scam or some service that has really lax rules.

Would be funny if the OP tried to scam someone who did know what they were doing, but still lost the BTC.
i.e. send the funds to a casino, loose, and then have the casino do a CPFP and still get thier BTC

-Dave

It's true that Sportsbet instantly credits your account long before the transaction gets confirmed, but you can't scam them. If you bet and win, you will never get your money until the original transaction gets confirmed. If you cancelled it, it's obvious that it never will. You are kind of scamming the bookie because you lost and they didn't receive the money (you played for free), but they didn't lose anything. Plus, I am sure they have systems in place to detect these things, and they would ban you if you tried it.

Im gonna say it without  mincing words, you are trying to get information to try to scam X page or people.

You want to take advantage of some system implemented by some pages of betting like for example Sportsbet here, who they credited your deposit without any confirmation, you cant withdraw, but i think you wanna make the bet and if you lose you want to cancel the operation.

Or you want to make that in a P2P transaction, and you are pure garbage man, i can imagine you sitting in a coffe shop and showing up to X person that the transaction its on the way, and when you take the money and run to other side , you are gonna cancel the trade.

I hope im wrong, but i really think im in the correct path.

It seems like homosapienstrader is trying to deceive someone into believing they paid/sent bitcoin for whatever reason, but they never did. Maybe I am wrong. He wants someone to see an incoming transaction in his wallet, notice the balance update (hopefully) without realizing it's fake. I see no reason why you would want to do that to yourself, hence I am thinking it's a malicious reason behind this question meant to trick another individual.

There were (quite a few) cases where the "overridden" transactions gets confirmed instead of the one with higher fees. While the chances are slim, they are non-zero and there are tons of factor at play here; extent of transaction propagation, amount of fee increment (if it violates minimum increase in feesor not), mining pool policy, etc. I don't think there are any implementations of software which wouldn't recognize opt-in RBF given that it has been introduced for years now.

You can do that too. Just create any valid transaction, broadcast it, and then use RBF to bump the transaction fee and send it to another address. On particularly dumb wallet software (smart wallets will drop it), you will still see the RBF-overridden transaction even though it will never be confirmed, because miners would want to include the transaction with a higher fee instead, and once that happens, the inputs of the other transaction become spent.

Then OP will not get what he wants.
He want the recipient to see the transaction, so it has to at least propagate in the mempools.

Maybe OP is finding a reason for those "missing" unconfirmed transactions used by scammers which is simply caused by an rbf~ed parent.

Actually, it is definitely possible. All you have to do is place in the transaction inputs, ANY pair of transaction ID and output index that either a) does not exist, b) exists and is not owned by you, or c) belongs to you but is not signed properly.

It's not going to float around in the mempool, but the transaction will immediately get rejected by all nodes for being incorrect.

There are a fair amount out there that do. I just did a check since I am taking one of my LN nodes offline. I saw the tx in my wallet. I then did a RBF to get it confirmed.
Probably would have dropped / disappeared within minutes.

Either way it's still the same point. Sending with 3 sat / vb will show up and probably never get confirmed.

Or, you could also send with a low fee and then send another TX out from there with a low fee and then RBF the parent TX.

No matter what it's still sketchy for the OP to ask.

-Dave

There's a big difference between the implementation of limits in the node software and the actual consensus rules.

If you'd change the constants defining the dust limit and minimum fee in bitcoin core's sourcecode (iirc, they're defined in https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.h) and compile the sourcecode, then get enough people to run your node's "implementation", you'd be able to create a 0 fee transaction with a 1 sat input and a 1 sat output and relay it to anybody running the binary you compiled without breaking any consensus rules (if i'm not mistaking). This is not a fake tx tough, it's just a transaction spending one unspent output with a value of 1 sat and creating an output with a value of one sat... At least, if you can find a one sat unspent output to spend (it won't be easy and it'll probably require running a patched wallet and maybe even the need to pay of a mining pool). Needless to say, the odds of such a transaction ending up in a block are very (very) close to 0.

The "problem" is that most people won't run your binary, they'll run the default binary which has a default value for the dust limit and minimum transaction fee... This means that anybody not running your binary will simply reject the transaction, eventough it's not breaking any consensus rules. They won't put the tx in their mempool due to the fact they no longer relay 0 fee transactions and they reject transactions with an output under the dust limit. So, you cannot use this method to scam anybody without putting in more effort than it's worth.

It doesn't congest the network in any meaningful way. If you attempt to broadcast a transaction with zero fee or a fee below the dynamic lower limit set by individual node's mempool settings, then nodes will simply not relay that transaction. Repeatedly try to do this, and nodes will simply blacklist your IP and ignore you.

You can't really, at the moment. Given that the vast majority of nodes run with default settings, anything below around 2.9 sats/vbyte at the moment will simply not be relayed, let alone confirmed. You could of course manually connect to a specific node which has increased its mempool limits, but then your transaction will just sit in the mempool of that one node and not go anywhere, which obviously achieves very little.

You cannot send with a 0 transaction fee.
You can send with a 1 sat / vb fee which will probably never get confirmed at this point.


You claim to be a trader and ask for money in another post, and then you ask for advice on how to create a fake transaction here.

Yeah that does not look shady at all.

-Dave

I've seen this in the past: it was possible to make blockchain.info show transactions that didn't exist anywhere else, and would never confirm. But that's a bug/exploit on the website, not on Bitcoin.
What are you trying to accomplish?

Rejecting a transaction paying zero fee isn't a consensus rule. Note that a transaction not paying any fee is non-standard, but it follows the consensus rules.
The default minimum relay fee is 1 sat, but there's nothing preventing nodes from decreasing that value and accepting transactions that don't pay any fee.

There is no fake node unless you talking about forking Bitcoin it would never be a Bitcoin once you fork BTC.

And in addition to the posts above, almost all miners and pools prioritize transactions with high fees to be included on the blocks they mined.

And all wallets do not allow zero fees unless you have your own node.

Also, nodes have a consensus mechanism almost all nodes are following Bitcoin's consensus rules. Like what you are planning to do the transaction will gets rejected once you broadcast a transaction with zero fees and if you spam or violate the rules consistently there is a possibility that your node will be banned.