Should this officially be implemented ? [Look Inside]

[Patatas]

Today while waiting for one of my transaction to get confirmed ,I wasted too much of my time figuring out how to rebroadcast the transaction with higher fees or speed up the existing one.Excuse me for not checking the network fees for that time before sending it.

Now my question is,should a broadcasted transaction be automatically dropped if it doesn't get confirmed in 'n' amount of time ? Right now,I don't know if my tx will ever get confirmed or it will be dropped off.I can't do much but wait and watch.Maybe there was a way in Core that the algo drops transactions if they don't get confirmed in certain amount of time ? 

[1714123311]

1714123311

[DannyHamilton]

Now my question is,should a broadcasted transaction be automatically dropped if it doesn't get confirmed in 'n' amount of time?

This is not possible in a decentralized system.

Maybe there was a way in Core that the algo drops transactions if they don't get confirmed in certain amount of time ? 

No.

[ranochigo]

Today while waiting for one of my transaction to get confirmed ,I wasted too much of my time figuring out how to rebroadcast the transaction with higher fees or speed up the existing one.Excuse me for not checking the network fees for that time before sending it.

Its pretty easy to be honest.

Now my question is,should a broadcasted transaction be automatically dropped if it doesn't get confirmed in 'n' amount of time ? Right now,I don't know if my tx will ever get confirmed or it will be dropped off.I can't do much but wait and watch.Maybe there was a way in Core that the algo drops transactions if they don't get confirmed in certain amount of time ? 

Transactions do not have a timestamp to it neither do the nodes have a synchronized time with each other. Since every node sees the transaction at a different time, they will not drop the transaction at the same time. In addition, if the transaction gets rebroadcast, the nodes wouldn't drop it at all. Its not up to you, anyone can do it.

[ivantosov]

Do you mean to write maximum block number for transaction?

[suzanne5223]

Today while waiting for one of my transaction to get confirmed ,I wasted too much of my time figuring out how to rebroadcast the transaction with higher fees or speed up the existing one.Excuse me for not checking the network fees for that time before sending it.

Now my question is,should a broadcasted transaction be automatically dropped if it doesn't get confirmed in 'n' amount of time ? Right now,I don't know if my tx will ever get confirmed or it will be dropped off.I can't do much but wait and watch.Maybe there was a way in Core that the algo drops transactions if they don't get confirmed in certain amount of time ? 

There is no way for you to drop transaction which has been sent but waiting for confirmation and I think it will be better for you to check the transaction predicting site https://bitcoinfees.earn.com/ next time before sending out  bitcoin in other to avoid this kind of situation. However, on this thread https://bitcointalk.org/index.php?topic=2204426.msg24415596#new you'll the person who'll fast the transaction for you.

[MartPlatform]

No, I think you should not do it officially. Bad effect to your coin. 

[Quickseller]

The only way this would be possible if transactions were only valid up until a maximum block number. This could be implemented and enforced via a soft fork.

The problem with this is that it could result in situations in which the miners are given incentives to orphan blocks.

[Thirdspace]

The only way this would be possible if transactions were only valid up until a maximum block number. This could be implemented and enforced via a soft fork.

The problem with this is that it could result in situations in which the miners are given incentives to orphan blocks.

yes exactly based on block numbers,
we have a way to lock fund by using lock_time
why not introducing drop_time for option to drop unconfirmed transaction?
this would be similar to TTL time to live of an unconfirmed transaction up to certain block number

Transactions do not have a timestamp but the 'n' amount of time here can be based on the block number
so eventhough all nodes not synchronized in time but they do synchronized in block numbers
would this against the principle of bitcoin as a digital currency
I don't quite get the second part, what/why given incentives to orphan blocks?

[Carlton Banks]

This feature already exists in Bitcoin, since version 0.12.0 I believe (i.e. nearly 18 months ago).

Transactions unconfirmed after a configurable time limit are kicked out of the local mempool. Default time limit is 1 week. Of course, the mempools of other nodes may retain transactions for a length of time that is not 1 week, because the option is configurable.

[Coding Enthusiast]

Just a little correction

This feature already exists in Bitcoin, since version 0.12.0 I believe (i.e. nearly 18 months ago).

Oct 3, 2015

Default time limit is 1 week.

2 weeks, still not changed.

[Carlton Banks]

Default time limit is 1 week.

2 weeks, still not changed.

Indeed, thanks Coding Enthusiast

[Thirdspace]

Just a little correction

This feature already exists in Bitcoin, since version 0.12.0 I believe (i.e. nearly 18 months ago).

Oct 3, 2015

Default time limit is 1 week.

2 weeks, still not changed.

Transactions do not have a timestamp to it neither do the nodes have a synchronized time with each other. Since every node sees the transaction at a different time, they will not drop the transaction at the same time. In addition, if the transaction gets rebroadcast, the nodes wouldn't drop it at all. Its not up to you, anyone can do it.

but it works locally (dropping on local mempool) and other nodes may (re)broadcast it again (read ranochigo post)
thus the unconfirmed transaction goes back into (local) mempool again as new unconf.tx
it would create never ending loop which only breakable by RBF or successful double spend transaction
but by setting certain synchronized time based on block number similar to lock_time,
the unconf.tx will be dropped completely by all nodes and never be re-broadcasted again past specified block number
or I misunderstood the way that protocol works?