New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarified reason & urgency for RBF #132

Closed
wants to merge 2 commits into
base: gh-pages
from

Conversation

Projects
None yet
3 participants
@taoeffect

taoeffect commented Mar 7, 2016

No description provided.

@taoeffect

This comment has been minimized.

Show comment
Hide comment
@taoeffect

taoeffect Mar 7, 2016

See discussion thread here: https://twitter.com/taoeffect/status/706635843801210880

(RT from @petertodd suggests approval.)

taoeffect commented Mar 7, 2016

See discussion thread here: https://twitter.com/taoeffect/status/706635843801210880

(RT from @petertodd suggests approval.)

@harding

This comment has been minimized.

Show comment
Hide comment
@harding

harding Mar 7, 2016

Contributor

I think the previous version was more correct, clear, and concise (but I'm biased, as I helped edit it). I do think that we could use the "stuck" terminology that's commonly used elsewhere to help illustrate this effect. For example, we could simply add a single word to the previous phrasing (shown in bold):

During the period when transactions are stuck waiting to be confirmed, some wallets would like to be able to update those transactions in order to increase their fee (which may help them get confirmed faster), compress multiple transactions into one, create background coinjoins (to improve privacy), or to perform a number of other useful actions.

Contributor

harding commented Mar 7, 2016

I think the previous version was more correct, clear, and concise (but I'm biased, as I helped edit it). I do think that we could use the "stuck" terminology that's commonly used elsewhere to help illustrate this effect. For example, we could simply add a single word to the previous phrasing (shown in bold):

During the period when transactions are stuck waiting to be confirmed, some wallets would like to be able to update those transactions in order to increase their fee (which may help them get confirmed faster), compress multiple transactions into one, create background coinjoins (to improve privacy), or to perform a number of other useful actions.

@taoeffect

This comment has been minimized.

Show comment
Hide comment
@taoeffect

taoeffect Mar 7, 2016

The previous wording fails to emphasize that from the user-perspective, Bitcoin has a very serious and potentially costly bug without RBF.

Whitewashing is not OK, and it is the reason why so many are confused and/or are against RBF right now. The wording of this PR addresses that problem.

That transactions can get stuck for days in limbo, and either get rejected or accepted can cause serious financial loss for many people.

taoeffect commented Mar 7, 2016

The previous wording fails to emphasize that from the user-perspective, Bitcoin has a very serious and potentially costly bug without RBF.

Whitewashing is not OK, and it is the reason why so many are confused and/or are against RBF right now. The wording of this PR addresses that problem.

That transactions can get stuck for days in limbo, and either get rejected or accepted can cause serious financial loss for many people.

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Mar 7, 2016

Member

meh on the proposed text; +1 on the single word update.

I disagree with the intensity of the argument here-- bitcoin has had this behavior for years and while it's obnoxious (I agree) and has frequently caused complaints over the years; it cannot be as fatal as you describe-- or otherwise it wouldn't have been tolerated so long. Many wallets have explicit support to support forgetting and responding coins in various ways ugly ways which work without replacement.

Bitcoincore.org should strive for a calm and objective approach and take care not to potentially exaggerate.

Member

gmaxwell commented Mar 7, 2016

meh on the proposed text; +1 on the single word update.

I disagree with the intensity of the argument here-- bitcoin has had this behavior for years and while it's obnoxious (I agree) and has frequently caused complaints over the years; it cannot be as fatal as you describe-- or otherwise it wouldn't have been tolerated so long. Many wallets have explicit support to support forgetting and responding coins in various ways ugly ways which work without replacement.

Bitcoincore.org should strive for a calm and objective approach and take care not to potentially exaggerate.

@taoeffect

This comment has been minimized.

Show comment
Hide comment
@taoeffect

taoeffect Mar 7, 2016

Bitcoincore.org should strive for a calm and objective approach and take care not to potentially exaggerate.

I agree 100%. Right now it is exaggerating (whitewashing) a problem that needs to be fixed.

bitcoin has had this behavior for years

This is false. Bitcoin has only recently begun to experience full blocks, not for years.

taoeffect commented Mar 7, 2016

Bitcoincore.org should strive for a calm and objective approach and take care not to potentially exaggerate.

I agree 100%. Right now it is exaggerating (whitewashing) a problem that needs to be fixed.

bitcoin has had this behavior for years

This is false. Bitcoin has only recently begun to experience full blocks, not for years.

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Mar 7, 2016

Member

@taoeffect The relevant size in question is the size miners are willing to produce; for years the bitcoin software had a hard coded maximum size (of 250k) for that target, and at many times blocks have been persistently full for long spans of time (which are also visible as flat spots on blocksize graphs). I can happily paste for you reports from users complaining that their transactions were stuck all the way back in 2012; and I have personally helped users manually double-spend their stuck transactions with higher fees dozens of times in the past. It is not true that this is something new.

Member

gmaxwell commented Mar 7, 2016

@taoeffect The relevant size in question is the size miners are willing to produce; for years the bitcoin software had a hard coded maximum size (of 250k) for that target, and at many times blocks have been persistently full for long spans of time (which are also visible as flat spots on blocksize graphs). I can happily paste for you reports from users complaining that their transactions were stuck all the way back in 2012; and I have personally helped users manually double-spend their stuck transactions with higher fees dozens of times in the past. It is not true that this is something new.

@taoeffect

This comment has been minimized.

Show comment
Hide comment
@taoeffect

taoeffect Mar 7, 2016

@gmaxwell The existence of some anomalies in the past is quite different from what used to be considered as anomalous behavior suddenly becoming everyday behavior for a far more significant fraction of Bitcoin's users.

But, by all means, if you want to shoot yourself in the foot and make life harder for yourself and your users, I can't stop you from doing so. I can say that I tried, so my conscience is clean.

Additionally, you will get no sympathy from me as Bitcoin users ramp up their demands on you to hard fork Bitcoin and increase the block size because their user experience has been destroyed simply because you can't be honest in your documentation.

taoeffect commented Mar 7, 2016

@gmaxwell The existence of some anomalies in the past is quite different from what used to be considered as anomalous behavior suddenly becoming everyday behavior for a far more significant fraction of Bitcoin's users.

But, by all means, if you want to shoot yourself in the foot and make life harder for yourself and your users, I can't stop you from doing so. I can say that I tried, so my conscience is clean.

Additionally, you will get no sympathy from me as Bitcoin users ramp up their demands on you to hard fork Bitcoin and increase the block size because their user experience has been destroyed simply because you can't be honest in your documentation.

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Mar 7, 2016

Member

I regret you've chosen to take this kind of unprofessional approach; feel free to characterize behavior that was exhibited for months at a time as 'anomalous' elsewhere; this kind of abuse isn't welcome here. Please refrain from using this repository in the future.

Member

gmaxwell commented Mar 7, 2016

I regret you've chosen to take this kind of unprofessional approach; feel free to characterize behavior that was exhibited for months at a time as 'anomalous' elsewhere; this kind of abuse isn't welcome here. Please refrain from using this repository in the future.

@gmaxwell gmaxwell closed this Mar 7, 2016

@bitcoin-core bitcoin-core locked and limited conversation to collaborators Mar 7, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.