Should this officially be implemented ? [Look Inside]

Thirdspace

hero member

Activity: 1232

Merit: 738

Mixing reinvented for your privacy | chipmixer.com

Quote from: Coding Enthusiast on November 15, 2017, 09:43:35 AM

Just a little correction

Quote from: Carlton Banks on November 15, 2017, 08:35:13 AM

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

Oct 3, 2015

Quote from: Carlton Banks on November 15, 2017, 08:35:13 AM

Default time limit is 1 week.

2 weeks, still not changed.

Quote from: ranochigo on November 11, 2017, 05:49:50 AM

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? Huh

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Quote from: Coding Enthusiast on November 15, 2017, 09:43:35 AM

Quote from: Carlton Banks on November 15, 2017, 08:35:13 AM

Default time limit is 1 week.

2 weeks, still not changed.

Indeed, thanks Coding Enthusiast

Coding Enthusiast

legendary

Activity: 1042

Merit: 2805

Bitcoin and C♯ Enthusiast

Just a little correction

Quote from: Carlton Banks on November 15, 2017, 08:35:13 AM

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

Oct 3, 2015

Quote from: Carlton Banks on November 15, 2017, 08:35:13 AM

Default time limit is 1 week.

2 weeks, still not changed.

Carlton Banks

legendary

Activity: 3430

Merit: 3080

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.

Thirdspace

hero member

Activity: 1232

Merit: 738

Mixing reinvented for your privacy | chipmixer.com

Quote from: Quickseller on November 13, 2017, 12:27:08 AM

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?

Quickseller

copper member

Activity: 2996

Merit: 2374

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.

MartPlatform

jr. member

Activity: 37

Merit: 1

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

suzanne5223

hero member

Activity: 2786

Merit: 657

Want top-notch marketing for your project, Hire me

Quote from: Patatas on November 11, 2017, 04:45:26 AM

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://bitcointalksearch.org/topic/m.24415596 you'll the person who'll fast the transaction for you.

ivantosov

newbie

Activity: 20

Merit: 1

Do you mean to write maximum block number for transaction?

ranochigo

legendary

Activity: 3038

Merit: 4418

Crypto Swap Exchange

Quote from: Patatas on November 11, 2017, 04:45:26 AM

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.

Quote from: Patatas on November 11, 2017, 04:45:26 AM

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.

DannyHamilton

legendary

Activity: 3472

Merit: 4801

Quote from: Patatas on November 11, 2017, 04:45:26 AM

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.

Quote from: Patatas on November 11, 2017, 04:45:26 AM

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

No.

Patatas

legendary

Activity: 1750

Merit: 1115

Providing AI/ChatGpt Services - PM!

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 ?

Topic: Should this officially be implemented ? [Look Inside] (Read 797 times)