RoxxR (OP)
|
Usually people want their transactions to confirm as fast as possible, but I was wondering, are there ways of making a transaction slower to confirm? Like taking 10 blocks or more to confirm?
I can only think of one obvious way, paying a very low fee. Obviously this would only work when the network is congested.
Can we think of any other ways?
Also, it used to be possible to make zero-fee transactions. Is this still possible in 2022?
|
|
|
|
witcher_sense
Legendary
Offline
Activity: 2450
Merit: 4415
🔐BitcoinMessage.Tools🔑
|
|
March 17, 2022, 09:55:59 AM |
|
I can only think of one obvious way, paying a very low fee. Obviously this would only work when the network is congested.
Can we think of any other ways?
If you don't want your transaction to be included in a block right away, you simply don't broadcast it to the network and wait for as many blocks as you want. Also, it used to be possible to make zero-fee transactions. Is this still possible in 2022?
You can manually construct a transaction even with negative fees. The question is will nodes or miners accept such a transaction? Also read this: https://bitcoin.stackexchange.com/questions/91124/how-to-send-zero-fee-bitcoin-transaction
|
|
|
|
ABCbits
Legendary
Offline
Activity: 3052
Merit: 8018
Crypto Swap Exchange
|
Can we think of any other ways?
Setup script to broadcast your transaction on specific time/date. Also, it used to be possible to make zero-fee transactions. Is this still possible in 2022?
You can manually construct a transaction even with negative fees. The question is will nodes or miners accept such a transaction? Almost all nodes won't accept 0-fee transaction since it's default Bitcoin Core behavior. Miner might include it, but you need to find out how to make your transaction enter miner mempool.
|
|
|
|
khaled0111
Legendary
Offline
Activity: 2702
Merit: 3035
Top Crypto Casino
|
|
March 17, 2022, 12:40:42 PM Last edit: March 17, 2022, 01:48:42 PM by khaled0111 |
|
You can use either nLockTime or CheckLockTimeVerify opcode based on your needs. Specifying an nLockTime value greater than the current block height will ensure your transaction will remain invalid and can't be mined till the block height become less than or equal to nLockTime. CLTV, on the other hand, is used to time-lock the output(s) of the transaction not the transaction itself. Meaning that your transaction can be confirmed but the receiver can't spend the outpu(s) before the specified block height. You can read more about TimeLocks here: https://en.bitcoin.it/wiki/TimelockYou can create a time locked address with coinb.in (do it offline) and the coins you send to the generated address will be locked until the block height/date condition is met.
|
|
|
|
garlonicon
Copper Member
Legendary
Offline
Activity: 914
Merit: 2200
Pawns are the soul of chess
|
|
March 18, 2022, 05:39:16 AM |
|
Also, it used to be possible to make zero-fee transactions. Is this still possible in 2022? You can make it in Bitcoin Core by using createrawtransaction. You can even send that to some nodes, if they have this setup in their bitcoin.conf: minrelaytxfee=0.00000000 blockmintxfee=0.00000000 But by default, miners don't accept free transactions (and nodes that do, usually also have other default settings like 300 MB max mempool size, also they will get the highest fees first anyway, because that's how getblocktemplate works with default settings). You can manually construct a transaction even with negative fees. The question is will nodes or miners accept such a transaction? Do you mean using SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, where the output is higher than the input? Then yes, in this case someone can pay fees for you.
|
|
|
|
pooya87
Legendary
Offline
Activity: 3626
Merit: 10993
Crypto Swap Exchange
|
|
March 18, 2022, 06:16:30 AM |
|
Like taking 10 blocks or more to confirm?
Another way of looking at your question is that you are asking for a way to put an additional and unnecessary burden on other nodes. A transaction that is not going to be mined for n number of blocks is going to cost the node that holds it in its mempool. It takes up space in the memory and also consumes bandwidth when they have to relay it to other nodes which is increased with n.
|
|
|
|
PrimeNumber7
Copper Member
Legendary
Offline
Activity: 1652
Merit: 1901
Amazon Prime Member #7
|
|
March 18, 2022, 09:36:48 AM |
|
Also, it used to be possible to make zero-fee transactions. Is this still possible in 2022?
You can manually construct a transaction even with negative fees. The question is will nodes or miners accept such a transaction? Almost all nodes won't accept 0-fee transaction since it's default Bitcoin Core behavior. Miner might include it, but you need to find out how to make your transaction enter miner mempool. No economically rational miner is going to accept a negative fee transaction. At least not intentionally. Some miners will allow for people to send transactions directly to them, with the guarantee the transaction will be included in the miner's (next) block, in exchange for a fee. I am curious if any of these miners have their software configured to reject transactions that include a negative transaction fee.
To answer the OP's question directly, the only correct answer is to use nLockTime to make the transaction invalid until x blocks in the future.
|
|
|
|
vjudeu
Copper Member
Legendary
Offline
Activity: 894
Merit: 2216
|
|
March 18, 2022, 10:11:14 AM |
|
No economically rational miner is going to accept a negative fee transaction. A negative fee transaction is invalid, unless it uses some sighashes, where it is possible to make it valid by adding some inputs. But even then, you probably need to recompile your client to reach that. Or you could have some proxy that would capture invalid transactions and store some of them, but probably doing changes in Bitcoin Core and making a custom version that would store more transactions would be easier. the only correct answer is to use nLockTime to make the transaction invalid until x blocks in the future It could be also possible to add some difficulty to the transaction, if some opcodes like OP_CAT or OP_SUBSTR would be re-enabled in TapScript.
|
|
|
|
PrimeNumber7
Copper Member
Legendary
Offline
Activity: 1652
Merit: 1901
Amazon Prime Member #7
|
|
March 19, 2022, 11:38:45 PM |
|
No economically rational miner is going to accept a negative fee transaction. A negative fee transaction is invalid, unless it uses some sighashes, where it is possible to make it valid by adding some inputs. But even then, you probably need to recompile your client to reach that. Or you could have some proxy that would capture invalid transactions and store some of them, but probably doing changes in Bitcoin Core and making a custom version that would store more transactions would be easier. The means of creating the transaction is irrelevant. The point is that you could create a tx with a negative fee (by modifying software the creates transactions), however that no miner is ever going to intentionally accept this transaction into their block. Doing so would not be rational.
|
|
|
|
larry_vw_1955
|
|
March 20, 2022, 01:18:24 AM |
|
The means of creating the transaction is irrelevant. The point is that you could create a tx with a negative fee (by modifying software the creates transactions), however that no miner is ever going to intentionally accept this transaction into their block. Doing so would not be rational.
the miner would have to subsidize the transaction using their block reward or some other mechanism.
|
|
|
|
pooya87
Legendary
Offline
Activity: 3626
Merit: 10993
Crypto Swap Exchange
|
|
March 20, 2022, 03:50:02 AM |
|
The means of creating the transaction is irrelevant. The point is that you could create a tx with a negative fee (by modifying software the creates transactions), however that no miner is ever going to intentionally accept this transaction into their block. Doing so would not be rational.
You don't have to modify the software to sign a transaction with SIGHASH_SINGLE|SIGHASH_ANYONECANPAY sighashtype flag. You just have to use the bitcoin core console since the UI doesn't have the option. https://bitcoincore.org/en/doc/22.0.0/rpc/rawtransactions/signrawtransactionwithkey/Such a transaction could be seen as "not-finalized" so it shouldn't be propagated in first place.
|
|
|
|
garlonicon
Copper Member
Legendary
Offline
Activity: 914
Merit: 2200
Pawns are the soul of chess
|
|
March 20, 2022, 08:01:19 AM |
|
Such a transaction could be seen as "not-finalized" so it shouldn't be propagated in first place. It shouldn't be, but it technically can be, as long as it will not be placed in a block. And that could be useful in some protocols, like "sell this for 1 BTC". All that is needed is creating transaction, for example as "0.5 BTC -> 1.5 BTC" and sign it with such sighash. Then, the buyer could attach some input and accept the trade. By the way, this sighash has some nice properties: negative fee, "0.5 BTC -> 1.5 BTC": Sell something for 1 BTC. zero fee, "0.5 BTC -> 0.5 BTC": Move coins for free, so "you pay my fees" transaction. positive fee, "0.5 BTC -> 0 BTC (OP_RETURN?)": Donation to anyone (probably miner, unless combined with something else). Also, SIGHASH_SINGLE bug could be used in the last case, just to reduce transaction size and skip one output. Or maybe SIGHASH_NONE, it would be even better (unless there is some amount left, then SIGHASH_SINGLE would do the trick).
|
|
|
|
PrimeNumber7
Copper Member
Legendary
Offline
Activity: 1652
Merit: 1901
Amazon Prime Member #7
|
|
March 20, 2022, 12:28:34 PM |
|
The means of creating the transaction is irrelevant. The point is that you could create a tx with a negative fee (by modifying software the creates transactions), however that no miner is ever going to intentionally accept this transaction into their block. Doing so would not be rational.
the miner would have to subsidize the transaction using their block reward or some other mechanism. Right. The block reward is the sum of block subsidy, and all inputs, minus the sum of all outputs. If a transaction has more outputs than inputs (in terms of total value), the difference would come out of the block reward. No miner is going to do this.
|
|
|
|
garlonicon
Copper Member
Legendary
Offline
Activity: 914
Merit: 2200
Pawns are the soul of chess
|
|
March 20, 2022, 01:05:24 PM |
|
If a transaction has more outputs than inputs (in terms of total value), the difference would come out of the block reward. The Bitcoin Core client in regtest says it is invalid: generateblock "bcrt1qlaf0ku3nhu26mffln8kn2rhgjfaduda9azzlfa" "[\"02000000018fa4883cae979495c8a9c1e7e52e10127950cd3a56a6c5c6ad327db85690e9f20000000000fdffffff0100e40b540200000016001484756196d612a86b3be4ea34fff3158fe5576c7c00000000\"]" TestBlockValidity failed: bad-txns-in-belowout, value in (50.00) < value out (100.00) (code -25) You can create some block in regtest and paste it here if you think it is possible. As far as I checked, each transaction has to be correct, so it is not possible to have some transaction creating coins out of thin air and some miner paying for that by taking less coins in the coinbase transaction.
|
|
|
|
martha1
Jr. Member
Offline
Activity: 94
Merit: 1
|
|
March 20, 2022, 01:17:13 PM |
|
Usually people want their transactions to confirm as fast as possible, but I was wondering, are there ways of making a transaction slower to confirm? Like taking 10 blocks or more to confirm?
I can only think of one obvious way, paying a very low fee. Obviously this would only work when the network is congested.
Can we think of any other ways?
Also, it used to be possible to make zero-fee transactions. Is this still possible in 2022?
Your question doesn't make any sense,if you want your transaction to arrive at X date just send it at that X date why you're going through all this hassle just to make it slower.
|
|
|
|
n0nce
|
The means of creating the transaction is irrelevant. The point is that you could create a tx with a negative fee (by modifying software the creates transactions), however that no miner is ever going to intentionally accept this transaction into their block. Doing so would not be rational.
the miner would have to subsidize the transaction using their block reward or some other mechanism. I don't think it would be possible to mine such a transaction; the block would get rejected. Let's remember that mining fee is simply the difference between your inputs and outputs. The difference between the amount being spent and the amount being received is the transaction fee (which must be zero or more) If it is negative, it means your input sum is smaller than the output sum, basically creating coins out of thin air. A block mined with such a transaction inside it, would be rejected by any node. To subsidize such transactions, the miner would need to modify the transaction and add more inputs, because block checks should (correct me if I'm wrong) check all transactions on validity one-by-one. So even if on a block-level it were to canceled out by some extra 'subsidy transaction' from the miner, not all checks would pass.
|
|
|
|
Charles-Tim
Legendary
Offline
Activity: 1722
Merit: 5190
Leading Crypto Sports Betting & Casino Platform
|
|
March 21, 2022, 08:06:18 AM |
|
The means of creating the transaction is irrelevant. The point is that you could create a tx with a negative fee (by modifying software the creates transactions), however that no miner is ever going to intentionally accept this transaction into their block. Doing so would not be rational.
Exactly. Creating the transaction will be highly irrelevant, miners are the ones that include transactions into block and they only accept transaction with incentives paid as fee, if a transaction is having a negative fee, then it means the person that make the transaction will be the one that will be paid fee while the payment can only be from miners. When miners are only encouraged by the fee, how would they include a transaction into a block in which they would be the one to lose (if provided there is a means miners can make the payment), definitely no miner will include such transaction in a block.
|
..Stake.com.. | | | ▄████████████████████████████████████▄ ██ ▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄▄▄▄ ██ ▄████▄ ██ ▀▀▀▀▀▀▀▀▀▀ ██████████ ▀▀▀▀▀▀▀▀▀▀ ██ ██████ ██ ██████████ ██ ██ ██████████ ██ ▀██▀ ██ ██ ██ ██████ ██ ██ ██ ██ ██ ██ ██████ ██ █████ ███ ██████ ██ ████▄ ██ ██ █████ ███ ████ ████ █████ ███ ████████ ██ ████ ████ ██████████ ████ ████ ████▀ ██ ██████████ ▄▄▄▄▄▄▄▄▄▄ ██████████ ██ ██ ▀▀▀▀▀▀▀▀▀▀ ██ ▀█████████▀ ▄████████████▄ ▀█████████▀ ▄▄▄▄▄▄▄▄▄▄▄▄███ ██ ██ ███▄▄▄▄▄▄▄▄▄▄▄▄ ██████████████████████████████████████████ | | | | | | ▄▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄ █ ▄▀▄ █▀▀█▀▄▄ █ █▀█ █ ▐ ▐▌ █ ▄██▄ █ ▌ █ █ ▄██████▄ █ ▌ ▐▌ █ ██████████ █ ▐ █ █ ▐██████████▌ █ ▐ ▐▌ █ ▀▀██████▀▀ █ ▌ █ █ ▄▄▄██▄▄▄ █ ▌▐▌ █ █▐ █ █ █▐▐▌ █ █▐█ ▀▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▀█ | | | | | | ▄▄█████████▄▄ ▄██▀▀▀▀█████▀▀▀▀██▄ ▄█▀ ▐█▌ ▀█▄ ██ ▐█▌ ██ ████▄ ▄█████▄ ▄████ ████████▄███████████▄████████ ███▀ █████████████ ▀███ ██ ███████████ ██ ▀█▄ █████████ ▄█▀ ▀█▄ ▄██▀▀▀▀▀▀▀██▄ ▄▄▄█▀ ▀███████ ███████▀ ▀█████▄ ▄█████▀ ▀▀▀███▄▄▄███▀▀▀ | | | ..PLAY NOW.. |
|
|
|
ABCbits
Legendary
Offline
Activity: 3052
Merit: 8018
Crypto Swap Exchange
|
|
March 21, 2022, 12:25:22 PM |
|
Your question doesn't make any sense,if you want your transaction to arrive at X date just send it at that X date why you're going through all this hassle just to make it slower.
While OP never state his intention, i can see why he ask such question. Some bank have feature "Scheduled Money Transfer" where customer just need to configure the schedule few times. It's more convenient than sending the money at specific time. To subsidize such transactions, the miner would need to modify the transaction and add more inputs, because block checks should (correct me if I'm wrong) check all transactions on validity one-by-one.
Is it even possible to modify signed transaction?
|
|
|
|
n0nce
|
|
March 21, 2022, 12:35:50 PM |
|
Is it even possible to modify signed transaction?
Yes, but you need have the signing key. I mean you could change the witness to modify the TXID, due the fact that in ECDSA you can easily calculate a second valid signature off of the original one, sure. But for adding more inputs, you're changing the body, so you do need to calculate a whole new signature of it, which requires the signing key and you basically double-spend the input. The transaction would need to be marked RBF though. So yes, very hypothetical scenario. It could happen e.g. that someone submits a transaction with negative fee and themselves, add a second input after noticing that it's faulty. To be clear, this isn't really modifying the signed transaction, it would be replacing it instead. And can't happen after it's mined as well, of course.
|
|
|
|
garlonicon
Copper Member
Legendary
Offline
Activity: 914
Merit: 2200
Pawns are the soul of chess
|
|
March 21, 2022, 03:11:45 PM |
|
While OP never state his intention, i can see why he ask such question. Some bank have feature "Scheduled Money Transfer" where customer just need to configure the schedule few times. It's more convenient than sending the money at specific time. Adding locktime and sending raw transaction to the recipient would do the trick. Also, it could be cancelled by double-spending the same coins without timelock, so that recipient's transaction will be invalidated. Is it even possible to modify signed transaction? Yes, just use something else than SIGHASH_ALL. You don't have to sign everything, that's only the default option, but could be easily changed if needed.
|
|
|
|
|